Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I deleted an old Windows XP partition and moved the Windows 7 partition to the left using gParted. The first reboots failed completely with the error "No operating system found".

Then I used a Windows 7 repair disc, got into command prompt and used different bootrec commands:

bootrec /fixboot

bootrec /fixmbr

bootrec /rebuildbcd

The last command is still saying

Total identified Windows installations: 0

Fortunately, through these commands I was able to start Windows again but it fails with the autochk program not being found.

autochk not found skipping autocheck

Running repair disc again I got the following repair details:

Session details
---------------
System Disk = \Device\Harddisk0
Windows directory = C:\Windows
AutoChk Run = 0
Number of root causes = 1

Root cause found:
Unspecified changes to system configuration might have caused the problem.

Repair action: System files integrity check and repair
Result: Failed. Error code = 0x57

How can I successfully boot into Windows now?

share|improve this question
    
You should expand more precisely on which partitions were where before, and how they were after. Also, I edited my answer below, because I fixed my similar problem. :) –  Redsandro Nov 7 '12 at 21:03

5 Answers 5

up vote 1 down vote accepted

There is no rocket science behind Windows booting. Windows Vista and later boot sequence on MBR disks:

  1. MBR code
  2. PBR code (partition boot record code of active partition)
  3. bootmgr on active partition uses BCD (boot config data)

Boot Configuration Data (BCD) for Vista and later is stored in a file "\Boot\BCD" on active partition.

When you move partitions which are critical for booting Vista (Win7, Win8) the data stored in BCD is out of sync with real partition address (disk id + partition offset) so boot fails.

To correct problem with BCD the utility bcdboot.exe can be used:

bcdboot c:\windows

where c:\windows is the root of the OS (Vista, Win7, Win8) which fails to boot, change drive letter if necessary to reflect drive mapping on your system.

To correct boot sector code the command -

bootsect /nt60 all /mbr

can be used.

The commands above are available in WindowsPE and WindowsRE and usually don't fail.

It is possible that some system critical files are also loaded relative to partition address so autochk.exe "\windows\system32\autochk.exe" cannot be found when you move partition start.

The address of a mapped partition is stored in Windows registry (HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices\DosDevices\C: for example)

share|improve this answer
    
This might do the trick but in my special case the BCD was stored on the partition that I deleted. Since I have no backup of this partition there will be no chance to get that working again, right? –  orschiro Nov 16 '12 at 6:52
    
In my case, the I also had to add /force to the bootsect command. Also, be careful about running that command with all if you are running the command on a server attached to a SAN! In my case, I ran bootsect /nt60 c: /mbr /force. (As well as the bcdboot c:\windows.) –  msemack Dec 11 '13 at 20:52

Found this post by "Yostage". it will help for sure

I had this problem, and none of the fixboot/fixmbr/bootrec commands helped. Here's what did fix it:

It appears that the C: is mismapped for whatever reason. In my case, I guess it's because my migration software didn't find it.

Boot into the recovery console and launch regedit.

Use load hive to mount your c:\windows\system32\config\system hive (I name it 'offline').

Now you're going to compare HKLM\System\MountedDevices (which is the recovery environment's device list) to HKLM\System\Offline\MountedDevices (which is the one for your failing windows install). In my case, I found that the recovery environment was correctly seeing C:, but the offline hive had the wrong disk signature for c:. (possibly because I deleted a recovery partition as part of the migration. So we need to put the right signature.

Look at the binary entry for DosDevices\C: in the recovery registry. Now go to the offline registry and fix your DosDevices\C: so it matches. In my case, I found it easiest to rename the bad DosDevices\C: to Z:, and then go through the \volume{guid} entries until I found the one that matches the working C:, and then rename that one to DosDevices\C:. Unload the hive in the file menu, and then reboot. After I did that, I was able to boot.

Other internet searches implied that simply deleting all the offline DosDevices entries would force them to get correctly recreated, but that didn't work for me.

(Thanks to Yostage: superuser.com/a/547260)

share|improve this answer
    
Protip for using Load Hive in regedit: You have to click one of the HKLM, HKCU, etc hives before it will work. It took me a while to figure out why this option was greyed out! You could also use REG LOAD from the command prompt before launching regedit. –  msemack Dec 11 '13 at 20:57

I had a similar problem after buying a laptop with SSD. I wanted to free some valuable SSD drive space to dual boot Linux, so I removed the 20 GB recovery partition (sda3) and the 8 GB system partition (sda0) at the beginning of the drive.

Now I got:

autochk not found skipping autocheck

Followed by a BSoD.

Since I removed recovery partitions from many a laptop and it never was a problem, I am pretty sure this system partition held some key files.

Using a bootable USB stick with live Linux, I put the backed up SYSTEM_DRV partition back in front of all the other partitions, but as a 350 MB in stead of 8 GB one because the rest was just valuable empty space.

As you probably know, removing and creating partitions often messes up the entries in the partition table:

[1st partition] -> sda3  
[2nd partition] -> sda2  
[3nd partition] -> sda1  

So I fixed the records with fdisk:

x // expert mode
f // fix count
w // write changes

Do this at your own risk. I highly recommend an annoying amount of backups!

Now it was well again. Mark the first one as boot:

[1st partition] -> sda1 * boot
[2nd partition] -> sda2
[3nd partition] -> sda3

And after rebooting, the system repair started. An automatic reboot, and checkdisk started. An automatic reboot, and Windows started!

Mission complete.

Since I am assuming that the folks over at Lenovo are not completely retarded, I am guessing that removing the empty space from the system partition messes up something, but I am not sure what that would be. At least it's not something you'll notice in everyday use.

Also as a side-note, throughout the years I have noticed that it gets increasingly easier to install and run Linux on pretty much everything, while at the same time it gets increasingly more difficult to keep Windows running after managing your drive. Why is that? You pay for it, so it has to be annoying? Pretend like booting is rocket science?

share|improve this answer
    
Same goes for your solution which will only work assuming I have a working backup which is not the case. –  orschiro Nov 16 '12 at 6:53

Please run SFC to find out if the autochk is broken. This is also common on drives which have whole disk encryption as Windows cannot gain access to the drive when WDE is turned on.

share|improve this answer

It appears that the drive partition was accidentally hidden. Use a partition tool to make it active again:

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.