We recently began using Microsoft's built-in SFC (System File Checker) as part of our FIM (File Integrity Monitoring) solution for PCI (Payment Card Industry) compliance. This great feature will compute hashes of core system files and compare those against originals looking for differences. If any are found, it can automatically replace those files with the original. The best part is that it incorporates all system updates into these checks so you can rest easy knowing that the checks are being performed against the latest, patched system files.

In most cases, this runs without intervention, but every now and then it needs a little help correcting any problems it encounters. If running a scan (via sfc /scannow) indicates there were unfixable errors found (eg. "Windows Resource Protection found corrupt files but was unable to fix some of them."), you can use the log file under C:\Windows\Logs\CBS\CBS.log to determine which file(s) are having problems being fixed. Microsoft's KB928228 article has great instructions on how to analyze this file. The basic gist is to run the following command and view the details only:

findstr /c:"[SR]" %windir%\logs\cbs\cbs.log >sfcdetails.txt

Search the resulting file for the phrase "cannot repair" - this should give you the file(s) that SFC is having problems replacing. To fix this, replace these file(s) manually with trusted versions (either from source media or from other working systems with same edition, bitness, and patch-level). It is probably best to review the text in the CBS.log file surrounding that entry to be certain you are replacing with the appropriate versions.

In very rare cases, you may not find the phrase "cannot repair" in the log file. In fact, you will find an entry to the contrary: "Verify and Repair Transaction completed. All files and registry keys listed in this transaction have been successfully repaired" at the end of the log file, but the SFC program will still still report that it found unfixable files. In these cases, I have found that renaming the file(s) specified in the logs and re-running SFC will correct the issue. You may need to take ownership, change permissions, or boot into safe mode to rename the suspect file(s) depending upon the system file in question.

Steve Smith just wrote an interesting blog post about using RAMDisk to speed build time for code projects. It's certainly worth reading, and might even get you thinking about other uses for RAMDisk to speed common disk-intensive operations.

http://stevesmithblog.com/blog/using-ramdisk-to-speed-build-times/

Intel is showing off a new chip that has 48-cores. Wow! Imagine a Dell R900 loaded with four 48-core CPUs, 256GB of RAM, and then outfitted with some blazing fast Fusion IO drives! That would be one powerful monster system.