When installing Visual Studio 2005 Service Pack 1, there are a number of errors that might occur due to insufficient disk space. You might see an error like the following that reads,

Error 1307.There is not enough disk space to install this file: D:WINDOWSSymbolsdllmfc80d.IA64.pdb. Free some disk space and click Retry, or click Cancel to exit.

Another common error code is Windows Installer error 2908, which indicates that Windows Installer could not register a particular component.

The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2908. The arguments are: {9BFFB8F8-F55F-10B2-B01F-C8B3B9A1E18E}

After rollback, applications that depend on Visual C/C++ (VC) runtimes including ATL, MFC, CRT, and OpenMP may not run anymore. Such applications include Windows Live Messenger and even Visual Studio 2005 itself. When attempting to start an application, you might see a dialog entitled “Application Error” that reads,

The application failed to initialize properly (0xc0150004). Click on OK to terminate the application.

If you attempt to repair Visual Studio 2005 or the .NET Framework 2.0, you might see an error that reads,

Error 25007.Error occurred while initializing fusion. Setup could not load fusion with LoadLibraryShim(). Error: The handle is invalid.

To work around this issue, remove orphaned Windows Installer packages and free additional disk space to meet the recommended minimum requirements to install SP1 depending on which applications you have installed, as documented on the download page for each patch package. You may need to install the VC redistributable package from a machine where SP1 successfully installed if you see an error like 25007 above when attempting to reinstall SP1. Read on for details.

What causes this issue is Windows File Protection and how files are sequenced in the patch to be installed. The policy file that controls to which version of a Windows side-by-side assembly an application is bound, and is used to update all applications using a particular assembly to the updated version, is sequenced to be installed before the updated binaries. On Windows XP where Windows side-by-side assemblies were introduced, and on Windows Server 2003, the VC merge modules (MSMs) install the policy, catalogs, manifest, and binaries directly using the Directory and File tables. Because of a problem in the native fusion library sxs.dll on those two platforms, using the MsiAssembly and MsiAssemblyName tables do not yield correct results when files are on use, typically during servicing scenarios.

If an error occurs between the time when the policy file is installed, and the binaries and manifest for an assembly are installed, the policy is not removed because of Windows File Protection. This is confirmed in the following log lines.

MSI (s) (00:C4) [11:38:18:281]: Executing op: SetTargetFolder(Folder=D:WINDOWSwinsxsPoliciesx86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773)
MSI (s) (00:C4) [11:38:18:281]: Executing op: FileRemove(,FileName=D:WINDOWSwinsxsPoliciesx86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c247738.0.50727.762.policy,,)
MSI (s) (00:C4) [11:38:18:281]: This following file was not removed, because it is protected by Windows: D:WINDOWSwinsxsPoliciesx86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c247738.0.50727.762.policy

After rollback completes, a policy is now redirecting applications that, in this case, link to the CRT 8.0 assembly including msvcm80.dll, msvcp80.dll, and msvcr80.dll to another version that does not exist (8.0.50727.762). Other assemblies might be intact because they too were under Windows File Protection as the Windows Installer rollback script tried to remove them.

Free additional disk space and reinstall Service Pack 1. If that fails with error 25007 because a custom action depends on the VC8 assemblies and the policy is redirecting to assembly versions that do not exist, you can also install the VC redistributable from another machine where SP1 applied successfully. You can find this under the directory BootStrapperPackages wherever the .NET Framework 2.0 SDK was installed, which by default is under the Visual Studio 2005 installation root. Though not recommended, you can also disable Windows File Protection, remove the policy file as shown in the Windows Installer log that redirects to a non-existent assembly, and re-enable Windows File Protection.