Visual Studio 2005 Service Pack 1 Rollback Breaks Some Applications

Visual Studio 2005 Service Pack 1 Rollback Breaks Some Applications

  • Comments 20

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:\WINDOWS\Symbols\dll\mfc80d.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:\WINDOWS\winsxs\Policies\x86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773\)
MSI (s) (00:C4) [11:38:18:281]: Executing op: FileRemove(,FileName=D:\WINDOWS\winsxs\Policies\x86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773\8.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:\WINDOWS\winsxs\Policies\x86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773\8.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 BootStrapper\Packages 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.

Leave a Comment
  • Please add 5 and 4 and type the answer here:
  • Post
  • PingBack from http://blogs.msdn.com/heaths/archive/2007/01/11/known-issues-with-visual-studio-2005-service-pack-1.aspx

  • I have heard from a couple of customers who tried to install Visual Studio 2005 SP1 , only to have it

  • Are the VC8 SP1 Merge Modules likely to expose the same partial-rollback problems when included in other setups, or are these problems specific to something special the VS 2005 SP1 install does?

  • This could happen for any application installation packages that merge the VC8 MSMs. There are two separate MSMs for each assembly, however: a payload MSM and a policy MSM. Generally, you should not include the policy MSM because it will redirect all applications. If you do, make sure it is merged after the payload MSM and you should be fine. 'tis better to have the payload and no publisher policy, than to have the publisher policy redirecting to non-existent assemblies. While we did test out-of-space scenarios it just didn't occur at the right time.

  • Is it possible that it installs but the SP1 is not seen in the add/remove programs? even after clicking the show updates, i cannot see it.  i do not recall any errors generated either.

    this sp1 breaks our build, i need to uninstall it but do not know how.

  • feta, it should show up in ARP. You can pass /uninstall to the EXE you downloaded.

  • ok, was able to install again and uninstalled it using what you have suggested. Turns out the build/release is broken because of the x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700

    stuff.  How do I ensure that this is on the target system?  Doing an xcopy to the WinSxS directory ot where I install the software?  We are using NSIS for our installer.

  • feto, I'm not sure I follow what you're asking. If you have uninstalled it, you've run into the same problem that those files are protected by WPF/WRP. You need to install SP1 for the new CRT to be available that devenv.exe and other executables require, as well as distribute the VC runtime (use the redists mentioned in the blog post, or use the non-policy_* MSMs to merge into Windows Installer-based setups) along with your applications built in VS 2005 SP1. Read http://blogs.msdn.com/astebner/archive/2007/02/08/mailbag-does-an-application-built-in-vs-2005-sp1-require-deploying-the-sp1-vc-runtime-files.aspx for more details on the latter.

  • Hi Heath, great blog you got here.

    I've installed the service pack on two machines now, in both cases successfully. I have, however, noticed that afterwards several other programs crashes. Adobe Illustrator crashes when deleting a word in a text (pressing backspace). ULead Mediastudio crashes when moving the pointer around in a video, and Norton crashes during startup. Since my computer installations are almost similar, and started crashing at the same time, I have a mounting suspicion of this service pack. Does this make sense at all, or am I looking at the wrong reasons for my crashes?

  • Anders, the VC team does a lot of regression testing on VC, which is the likely culprit. That said, it isn't impossible to think that could be causing problems. Unfortunately, it's difficult to say. Since you have VS installed, you should be seeing a crash dialog that gives you an opportunity to debug the application. When you attempt to, you can create a crash dump file and send it to the appropriate software manufacturers.

  • This SP1 is a TOTAL LOAD OF CRAP! Man, that's typically Microsoft.

  • Out of the many presented/researched solutions, installing the C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86\vcredist_x86.exe (file version 2.0.50727.762) from a successfully updated VS 2005 system onto a rolled back system seemed to be the most painless route.  Only time will tell if stability will be an issue.

  • Where to get Visual Studio 2005 and the .NET Framework 2.0 Where to download the .NET Framework 2.0 redistributable

  • I also ran out of disk space during the SP1 install and ASP.NET 2.0 wasn't operational after the rollback. The ASP.NET tab that allows choosing the framework version was even missing from IIS.

    I got the Error 25007 when trying to repair the .NET 2.0 framework per the instructions on KB908077.

    Removing the files mentioned in VS80sp1-KB926601-X86-ENU-msi.0.log file with the lines "This following file was not removed, because it is protected by Windows" fixed my problem.

  • my machine starts to whine when i am running the service pack.  Any solution to this?  

Page 1 of 2 (20 items) 12