IMHO Some good advice for recovering a fully working system when sfc reports a non repairable issue

You may or may not find this useful but it was in my case the only way to get a 100% OK score using sfc /scannow on Windows 7 64bit. I assume that this suggestion will work equally well for any OS that supports sfc.

First of all a link: http://support.microsoft.com/kb/929833 - this is how to use sfc and resolve any issues it finds that it cannot repair. (you can possibly ignore the way it tells you to recover the file(s) if the method below works for you)

This was the error I was getting after running sfc /scannow and then using the instructions from the MS KB item above to locate the errors it found:

2011-06-09 12:18:00, Info CSI 00000193 [SR] Cannot repair member file [l:24{12}]"netl160a.inf" of netl160a.inf, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type = [l:24{12}]"driverUpdate", TypeName neutral, PublicKey neutral in the store, hash mismatch
2011-06-09 12:18:00, Info CSI 00000195 [SR] Cannot repair member file [l:24{12}]"netl160a.inf" of netl160a.inf, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type = [l:24{12}]"driverUpdate", TypeName neutral, PublicKey neutral in the store, hash mismatch
2011-06-09 12:24:11, Info CSI 000002ed [SR] Cannot repair member file [l:24{12}]"netl160a.inf" of netl160a.inf, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type = [l:24{12}]"driverUpdate", TypeName neutral, PublicKey neutral in the store, hash mismatch
2011-06-09 12:24:11, Info CSI 000002ef [SR] Cannot repair member file [l:24{12}]"netl160a.inf" of netl160a.inf, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type = [l:24{12}]"driverUpdate", TypeName neutral, PublicKey neutral in the store, hash mismatch

When I looked at the files concerned it was not clear at all what the issue was apart from the fact that in one location the netl160a.inf file when loaded into notepad showed up as a binary type file rather than a text file. On looking at the same location on a VM I had set up some time back this was an issue as the file showed there as text. I replaced the file on the installation that had the problem with a text version and re-ran sfc but the problem remained the same 4 issues as above, and sfc could not repair the file(s)

When this issue came to light I looked back at the contents of the rolling archives I had and all of them showed the netl160a.inf file to be wrong and looking like a binary file. So I had no idea when the issue arose and I was going back some two months or so. The oldest was previous to the installation of SP1 so it was not an SP1 induced issue.

I also looked on the internet and found no real help as to how (or where) to recover the files manually. The SP1 exe or the original CD.

What I decided to do was to use an archive that I set up initially when installing Windows. In this instance when I installed windows and right after the installation, before I did anything other than some small basic tweaks I backed it up using ATIH. That archive was done nearly two years ago.

I backed up the current version of windows on my system and restored the basic archive I took two years ago. After that was restored I used windows update to bring it up to date and that also included W7-64Bit SP1. When this was complete I took a look at the netl160a.inf files and these indeed now looked like I would have expected them to text, not binary.

I now took an updated archive of the updated fully patched basic image and stored that as an update to the original.

I then restored the archive of the current version I took earlier and then did a search for all the net1160a.inf files. There were some 11 items in the result. I then use ATIH to open the updated basic archive and located those files/locations and asked ATIH to recover them. After the recovery completed I ran sfc /scannow and now I have no errors! I quickly took a backup and now hopefully things will remain correct.

The moral of this tail is:

1). Run sfc /scannow (as administrator) and if it is clean take a full backup and pop it away somewhere safe.

2). Run sfc /scannow on a regular basis just to ensure your system stays in peak condition.

3). Whenever the fancy takes you keep that "safe" archive up to date and ensure the before you commit it to safe keeping the sfc /scannow is 100% OK

4). If ever you have a problem you can use the same method as I did above to "fix" (hopefully) the issues it raises without too many problems and with just a bit of your time to achieve a result.

5). If you ever install a new OS take an archive as soon as possible after it is installed and working (Activated as well) - you never know when it will come in useful!

I hope that this will help should you find an issue that same as I did.

BUT, and there is always a BUT you must try to ensure that the files you restore are relevant to the system you are trying to fix, otherwise you may end up making the issue worse than it is. So to be sure backup and validate the backup make a copy of the backup and be absolutely certain you can get back to square one should thing not work out quite as you had hoped. Then you can at least try again and/or obtain some advice from elsewhere.