Recently, I was helping a colleague troubleshoot an installation error in the .NET Framework 3.5 SP1 on Windows Server 2008. I wanted to describe the specific issue, and also explain how we narrowed down the issue because I think these troubleshooting techniques could be useful for investigating other types of .NET Framework 3.5 or 3.5 SP1 installation failures on Windows Vista or Windows Server 2008.
How to narrow down this issue
In this scenario, the .NET Framework 2.0 SP2 component was failing to install during .NET Framework 3.5 SP1 setup. We started by looking at the log file named %temp%\dd_dotnetfx35install.txt, and found the following error:
[08/08/08,11:11:11] Microsoft .NET Framework 2.0SP1 (CBS): CBSComponent Action: CreateProcess launched with cmd line : C:\Windows\system32\WUSA.exe “C:\Windows\system32\WUSA.exe” “c:\e3e05fbe88ad4e54ff9203e6\wcu\dotNetFramework\dotnetmsp\x86\NetFX2.0-KB948609-v6001-x86.msu” /quiet /norestart
[08/08/08,11:11:11] Microsoft .NET Framework 2.0SP1 (CBS): C:\Windows\system32\WUSA.exe exited with return value 2147549183
[08/08/08,11:11:11] InstallReturnValue: GFN_MID NET Framework 2.0SP1 (CBS), 0x8000ffff
Even though this log says that the component is the .NET Framework 2.0 SP1, the package that was actually failing in this case was the .NET Framework 2.0 SP2. We know this because the package being installed is named NetFX2.0-KB948609-v6001-x86.msu (which is the .NET Framework 2.0 SP2 package), and because the .NET Framework 3.5 SP1 installs the .NET Framework 2.0 SP2 and 3.0 SP2 as prerequisites (not 2.0 SP1 and 3.0 SP1). The package ID in this log file was not updated between the .NET Framework 3.5 and 3.5 SP1.
Since the package that was failing in this case is an OS update package, we continued this investigation by looking at the Windows OS update log file named %windir%\logs\cbs\cbs.log. We found the following error in that log file:
2008-08-08 11:11:11, Info CBS WER: Generating failure report for package: Package_for_KB948609~31bf3856ad364e35~x86~~6.0.6001.3053, status: 0x8000ffff, failure source: Resolve, start state: 0, target state: 7
2008-08-08 11:11:11, Info CBS Exec: Processing complete. Session: 29949001:229928128, Package: Package_for_KB948609~31bf3856ad364e35~x86~~6.0.6001.3053, hr: 0x8000ffff
This error information did not help much, but further investigation in cbs.log showed that other non-.NET Framework update packages were also failing with the same 0x8000ffff error code. Based on that, we were able to determine that this error was a general problem with the OS update installation engine as opposed to a specific .NET Framework setup issue.
We had some colleagues on the Windows deployment team help us debug this further, and found that there was some kind of problem with the Cryptographic Services on the system, but we did not yet know what. Eventually, we found some information in the event log on the system that indicated that there were some missing permissions that prevented the Cryptographic Services from being able to access the catalog database.
How to resolve this issue
In order to resolve this issue, we had to use the steps described in this blog post in order to grant the BUILTIN\Users group read access to the system drive.
The Cryptographic Services runs using Network Service credentials, which means that it requires the Users group to have read access to resources that it needs to be able to access when it runs.
Another possible resolution for 0x8000ffff errors
I recently found this forum thread that contains some additional suggestions that might be helpful if you run into a 0x8000ffff error while trying to install a Windows Vista or Windows Server 2008 OS update. If the above suggestion does not work on your system, I’d suggest looking at this forum thread as well.
General advice for troubleshooting .NET Framework install failures on Windows Vista and Windows Server 2008
When troubleshooting .NET Framework 3.5 or 3.5 SP1 installation issues on Windows Vista and Windows Server 2008, it is important to remember that some of the failures can be caused by OS update installation engine problems. I usually use the pattern described above to narrow down this type of issue. Specifically, I do the following:
- Start by opening %temp%\dd_dotnetfx35install.txt and searching for the string errorlog event to narrow down which component of the .NET Framework is failing to install
- If you are on Windows Vista or Windows Server 2008, and if the failure is in the Microsoft .NET Framework 2.0SP1 (CBS) or Microsoft .NET Framework 3.0SP1 (CBS) component (or their 64-bit equivalents), then you will typically need to look in %windir%\logs\cbs\cbs.log, %windir%\WindowsUpdate.log and/or the event logs for more in-depth error information because the .NET Framework 2.0 and 3.0 service packs are installed as OS update packages on Windows Vista and Windows Server 2008, and because of that, they will report information into the Windows update installation log files during their installation processes.
When looking in cbs.log and/or WindowsUpdate.log, it is useful to attempt to match up the time stamps from the dd_dotnetfx35install.txt in order to better correlate log entries. It is also useful to look for the same error code from other Windows update packages in order to determine if the problem is specific to .NET Framework updates or if it is a more general problem with all Windows updates being installed on the system.
<update date=”3/12/2009″> Added a link to a forum post that can help resolve some types of 0x8000ffff errors. </update>