As I mentioned earlier I've been working on a Dell laptop trying to get it to auto check disk at boot time. When I first looked into the issue using Google the sites returned all discussed the only solution to the problem was to perform a clean Windows 7 installation. The reason was because I was looking up a specific error message generated by chkdsk, when run from the recovery command prompt. The error said chkdsk could not write to the event log and gave a Windows error / return code of 50. These article also went on to say the Windows SFC (Windows Resource Checker) always reported there was an existing SFC running and the user should reboot to clear it and then try again. Yet, upon trying again the person would find the same error message / condition. Their solution in these article was a complete clean installation of Windows 7.
Honestly, I really didn't think this was all there was to do and after some additional resource, discovered there are some things to try before reinstalling. I'm hoping Google will (in time) pick up with blog and people will find it and maybe save themselves the time and trouble to reinstalling Windows.
In the case of the "SFC" command, I was able to get it working by reading the help. There are two command line options one needs to use when running the command on an OFFLINE Windows system. By OFFLINE Windows system, I mean you boot and run Windows from another source (DVD, USB, RAM drive, etc) than the boot drive with the Windows system in trouble. These parameters / options are:
- /OFFBOOTDIR For offline repair specify the location of the offline boot directory
- /OFFWINDIR For offline repair specify the location of the offline windows directory
An example of using them is:
sfc /SCANFILE=d:\windows\system32\kernel32.dll /OFFBOOTDIR=d:\ /OFFWINDIR=d:\windows
Please take note of the example using the D: drive instead of the C: drive! When you run from say a DVD or the recovery console, the boot drive of the main Windows system (most likely) will be the D and not the C drive. Yes, there is a C drive, but not of the main bootable system.
NOTE: When you run the SFC command it generates a LOG file called CBS.log. In the case of booting from the DVD, I found the CBS.log file on the X: drive (X:\Windows\Logs\CBS\CBS.log) and not on the D: or C: drive.
NOTE: The SFC command generates lots of messages in the CBS.log file and finding the messages you need to help determine what is wrong is well, like, finding a needle in a haystack. I found searching for select key phrases helped me a lot in finding the error with the autochk.exe command.
These key phrases are:
- Cannot repair
- Could not reproject corrupted file
- source file in store is also corrupted
- Hashes for file member
In my case I used two methods to locate these strings, but on a completely running Windows there are at least three method:
- type CBS.log | find /I "<phrase>"
- findstr "<phrase>" CBS.log
OK, I've been talking about the SFC command and not the auto check disk at boot time, but honestly, they go and in hand. First, I discovered the error about not being able to write to the event log with a return code of 50 is a VALID message. It is OK! The CHKDSK command ran OK.
Once I realized I should be checking the D: drive instead of the C: drive, well, things really improved. I was able to resolve all issues on the C: drive, but still the autochk.exe file wasn't valid and the stored copy of autochk.exe was still corrupted, too.
In my case, I found two methods to correct the file.
- The DVD I used to boot Windows was a "Windows 7" "Service Pack 1" DVD from Dell and contained a valid autochk.exe file.
- I have two Windows 7 Ultimate x64 workstations and their copies of autochk.exe were valid. Thus copying those files over would also work.
I choose the first method, using the DVD copy. Obviously it was the quickest choice to execute in this case. After finding all the copies (by using the dir command), I copied the files from the "X:" drive to the "D:" drive. NOTE: You MUST make sure you copy the correct version (e.g. 64-bit verses 32-bit) and the version your system uses. What I did was look at the directory names on both the "X:" and "D:" drive and copy on a one to one match. This means I copies from "X:" to "D:" with the directory names matching, except for the drive letter. An example is: "X:\Windows\System32\" and "D:\Windows\System32\" There are several places to match up. Doing it this way, I ended up fixing both the main windows system and the stored copy the SFC command uses (from what I can tell).
I validated this fix by booting the system with the dirty bit set and guess what? Yup, problem fixed!! The system ran the check disk command automatically at boot time and ran it ONLY once.
NOTE: Please note there are other methods to fixing this issue, dealing with the registry. Automatic check disk at boot time can fail if the registry isn't set up correctly. In my case, this was not issue. My issue was a corrupted autochk.exe file and stored copy also having some level of corruption. You need to look into the issue on your system and determine the cause before applying the fix.
The key points to take way from this blog are:
- The SFC command has options for running it OFFLINE! When you run from any location other than your active / main Windows system (e.g. DVD, recovery, etc), you need to use these OFFLINE options.
- The boot drive for your Windows system (most likely) won't be the C: drive. In my case it was the D: drive.
- The CHKDSK.exe generated error message about not being able to write to the event log and error 50 is OK, when running from the recovery or DVD.
- There are more than one solution to this problem and this blog only discusses what worked for me. You need to do your own research.
- I wrote this blog because I found some bad information and am hoping when people do a Google or Yahoo or Bing or whatever search they'll find this blog along side the bad information saying the solution is to reinstall. You might need to reinstall in the end, but you need to know some facts about CHKDSK and SFC before making that decision.
OK, enough for now. Oh, yeah, I know . . . strange finding Windows help on a Scan2Go wikia, but hey, this is where I blog.