Windows Explored

After logon, a user was being notified by Windows that the master file table was bad. The error presented was: “The file or directory C:\$Mft is corrupt and unreadable. Please run the Chkdsk utility.”
The tech followed the advice in the balloon pop-up and set the workstation to run a chkdsk at the next restart. However, the chkdsk failed to run, even after setting it again and again. I was asked t assist and started by remotely looking at the file properties of autochk.exe, the file that is responsible for running chkdsk. I compared it against the same file on another workstation. I could immediately see that there might be a problem. The normal autochk.exe is on the left. The one on the right is from the user’s workstation that failed to run the chkdsk.

I wasn’t entirely convinced, though, so I turned to SigCheck from SysInternals. SigCheck is simple command line tool that verifies digital signatures and version info for files. I ran it against both autochk files, the good one on the top and the potentially bad one on the bottom:

Yep, looks like a bad autochk.exe on the problem workstation.

Another method to find out if your suspect file is bad is to load it into Dependency Walker. The good file:

The bad file:

Looks like a bad link checksum. What does that mean? That the file has been modified after its build. More specifically: “Link Checksum: The module checksum from when the module was built. This value is set by using the linker’s /RELEASE command line option. If this linker option is not specified, then the checksum may be zero. This value will be shown in red if it is not zero and does not match the actual module checksum. If the values do not match, it means that the module has been modified after it was built.”

To quickly resolve, you can delete or replace the file with a known good one. Since autocheck.exe falls under the guard of Windows File Protection, when you attempt to delete it or replace it, it will restore itself from the dllcache folder in C:\Windows\System32. If the version in dllcache is stable, then the problem should be corrected. Otherwise, if the file in dllcache is also bad, then you should replace the problem file in dllcache with a working file and then delete the one in the system32 folder. Alternatively, you can use the System File Checker. This will scan Windows for bad system files and replace, which may also help clear up other unexplained issues. This can be started from the command shell or the Windows run dialog by typing sfc /scannow.

In the case here, after deleting the autochk.exe file in the system32 folder, it was replaced by the one in dllcache and at restart the chkdsk utility successfully ran.