Repairing the .NET Framework in Windows Vista/7

These days I do a considerable amount of data recovery for my clients, and as you might expect, when dealing with failing drives, it isn’t always possible to recover all of the information.  Even the sophisticated hardware-based imaging tools I have can’t always extract every sector from a bad drive.

As such, I recently imaged a Windows 7 hard drive and retrieved something above 99% of the data.  This left very few files corrupt (and Windows was bootable following a chkdsk /f operation), but one item which was not working properly was the .NET Framework.  Problem is, unlike in previous versions of Windows, repairing the .NET Framework in Windows 7 isn’t as simple as removing/repairing all of the .NET Frameworks (either via Add/Remove Programs or using a cleanup tool and reinstalling them one-by-one).  Thanks to Aaron Stebner for his excellent reference material on this subject, by the way.

On Vista and 7, many .NET Framework versions are actually integrated into the OS.  As a result, when damaged files are responsible for its failure, you can often correct the problem using sfc /scannow.  However, when this fails, there’s actually a pretty straightforward way of making them work.

The catch is that the registry entries have to be intact.  There is, unfortunately, no easy way to restore these entries without a repair install (or “in-place upgrade” as it’s called in Vista/7).  In the event of disk failure and recovery, it’s very likely that if you’re able to boot, the registry is in working condition.  So if an sfc operation fails, it’s most likely that the file in the recovery store is also corrupt.  You can verify this by checking the CBS log for SFC entries (denoted by [SR]).  An easy way of doing this is to run this command once the sfc has finished its operations:

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

This command searches the CBS log for entries related to SFC operations and outputs all of the matching lines to another file called sfcdetails.txt.  If a corrupt file is found in the store and cannot be used to repair another damaged system file, you’ll see an entry like this one:

[SR] Could not reproject corrupted file {filename}; source file in store is also corrupted

My solution?  Pretty simple really; from a healthy Windows 7 64-bit system (the same OS as the patient PC), I backed up and then manually copied all files within these directories:

%windir%\Microsoft.NET\assembly
%windir%\Microsoft.NET\Framework
%windir%\Microsoft.NET\Framework64

As far as I know, the contents of these directories on identical, up-to-date Windows versions are standardized.  My suspicions were validated when, upon the next boot, the patient PC was suddenly working perfectly, with no adverse side effects!

By the way, while we’re on the subject of the SFC, one more solution to the problem is to simply replace every file it can’t repair as detailed here.  But you can also copy good versions of the files to the winsxs directory in the proper location and then perform a subsequent SFC operation to have it replace them for you.  Either approach works!

Donate to say "Thanks" if this post has helped save you time and money! 🙂

3 thoughts on “Repairing the .NET Framework in Windows Vista/7

  1. do i completely copy & remove all files in framework folder after backing up then re-copy them

Leave a Reply

Your email address will not be published. Required fields are marked *