I wanted to make everyone aware of a new blog entry I wrote for my teams blog regarding .Net servicing issues. It’s located here: http://blogs.technet.com/b/askcore/archive/2010/07/12/are-you-opening-up-a-net-case-with-microsoft.aspx
Because the .Net Framework is both an inbox and out of box installation, it can routinely hit my team as well as some of the developer teams. This should help you get the information you need to get gathered ahead of a support phone call to alleviate any issues with case routing when you open the issue.
Hope this helps….
I asked Aaron Stebner what he thought was the best way to repair a version of Dot Net that was built into the OS and he said booting with the DVD and doing a repair. What is your opinion on that ? Do you agree that it is the best way ?
How safe do you believe running the SFC is ? Will the SFC ask for the DVD and replace newer files with originals ? If so is that a smart thing to do ?
If the in-box component is corrupted, then yes, an inplace upgrade would probably be your best option unless we could find the manifest that is corrupted and repair it from another machine.
As for SFC, it will not ask for any kind of media because thats what the component store is there for. SFC is completely safe for running against the types of issues you're looking at though and I would recommend it and CheckSUR before ever rebuilding a machine.
Should a person go into Programs and Features and remove the Dot Net version first before booting with the DVD and doing a repair or doesn't it matter ?
Yes, that would be prudent troubleshooting before simply reinstalling. When troubleshooting servicing issues the main thing is to attempt to determine exactly what the problem is. Is the problem a corrupted file? Those can be replaced typically. Is the problem a corrupted registry entry or manifest? Those can be a little trickier. Or is the problem a corrupted image (this is actually the most common root cause for many companies), if thats the case then nothing is going to resolve the problem aside from rebuilding the machine from a new image.
What I meant was say you are at the point where the only thing that is going to fix it is booting with the DVD and doing a repair. Should you first go in and remove the Dot Net from Programs and Features before booting with the DVD and doing the repair to get rid of it and start clean or doesn't the repair process care.
Gotcha. In this case, no, we wouldnt care. We'll rebuild the component store as part of the reinstallation so removing it would have no effect.
What about the registry and permissions ? Does the DVD rebuild fix them also ? As far as I have learned it does not. So if not wouldn't the best course of action be :
1) Remove from Programs and Features
2) Boot with the DVD and run repair
3) Reboot without the DVD and readd in Programs and Features
I would think that this procedure would save possible further debugging time later on.
We will fix some issues in the registry, but not all of them. Most of the time, .Net issues that I have seen tend to be binary related and not registry. That's not to say they dont occur though. Removing the files prior to the reinstall wouldnt really change the registry values you're looking to change, so that wouldnt be any better than just reinstalling the OS.
"As for SFC, it will not ask for any kind of media because thats what the component store is there for."
Hypothetically, if the media were mounted, and WRP could talk to the servicing stack, then a file could be retrieved from the 'media', if the component store copy was corrupt, just as XP can seach <CD>\i386 if the DLLCache is missing files. Just a thought.
Dean said: "What about the registry and permissions ? Does the DVD rebuild fix them also ?"
joscon said: "We will fix some issues in the registry, but not all of them."
This is interesting, especially when considering the advice of the following Microsoft support article:
"The use of “secedit /configure” to import the default security template, dfltbase.inf, is unsupported nor is it a viable method to restore default security permissions on Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 computers."
Other than options like using System Restore, the best option that article offers (IMO), is to restore using a preconfigured template. That is, "ahead of time". Another candidate for FirstLogonCommands?
re: SFC comment - Not exactly, you could mount media in Win7 using DISM and pull a good copy of the version on that media into your directory to replace a corrupted file. It wouldnt have any hardlink protection until it was serviced the next time though.
Understood, but in my hypothetical example i was assuming the copying of the file from the mounted media and updating of the hardlink projection was occuring due to programming code, and not user intervention. Having said that, is that not more or less what happens when known good copies of files are retrieved from \windows\winsxs\backup ? Is this folder the equivalent of XP's \windows\system32\dllcache ?
For SFC it is. My example was a way to recover a file that was also corrupt in the backup directory of the component store. That's the only time you would need to do that. The component store is the equivalent of the dllcache in XP (to a greater extent)
Right, I'm with you now. :-)
Re the folder comparisons, isn't winsxs actually closer to Windows\i386 in XP? That is, it's really the totality of Windows (albeit componetized), and not just a backup for protected files. Isn't having the full component store on %systemdrive% at least part of the reason that SFC can be run offline in Vista and later, but not XP? I understand that the search order for WRP is winsxs > winsxs\backup, compared to dllcache > i386 for SFP in XP. Perhaps trying to compare the latest OS's to XP and earlier is underplaying the importance of winsxs, especially considering people wanting to delete or 'trim' it, knowing that the dllcache was purgable in XP?
Just one more question regarding analogies, in XP the checksums for the protected files was held in a DLL, SFC.dll I think. Where are the checksums now stored, is it the catalog files?