Heath Stewart's Blog

Do not repair VS 2008 SP1 from installation media

If you need to repair Visual Studio 2008 once SP1 has been applied or wish to change which features are installed, you cannot run setup.exe from the original installation media.

When you run repair from media you may see an error like, "A problem has been encountered while loading the setup components. Canceling setup."

Workaround

Open the Control Panel and go to Add/Remove Programs, or on Vista click on the "Uninstall a program" link under Programs. Find Microsoft Visual Studio 2008 (the exact product name will vary based on edition and language installed) and click on the Uninstall/Change button. When setup launches and components are loaded, you will be asked to repair, change features, or uninstall. Choose the option you which to perform and continue as directed.

Details

Visual Studio is actually a collection of different installation packages, just as VS2008 SP1 is a collection of different installation packages. VS2008 SP1 replaces some of the original packages using minor or major upgrades and patches other products. This changes information about the products originally installed like the ProductCode and/or ProductVersion. This affects the detection logic that setup.exe uses to determine what to do when installing, repairing, or uninstalling the product.

This information is stored both on the installation media as well as on your hard disk under the target installation directory. For various reasons including that media is often write-protected, we can only update this information stored on your hard disk. So once SP1 is installed, the detection and package information on the installation media and on your hard disk are out of sync and only the copy on your hard disk contains the correct information.

VS 2008 SP1 fails to install because of missing packages from the cache

Some customers are reporting that Microsoft Visual Studio 2008 SP1 is failing to install with the following error in the HTML log you can view from the error dialog.

Patch (C:\Users\heaths\AppData\Local\TEMP\WebDesignerCore_KB950278.msp) install failed on product (Microsoft Office Enterprise 2007). Msi Log: Microsoft Visual Studio 2008 SP1_20080816_141317516-Microsoft Office Enterprise 2007-MSP0.txt

Final Result: Installation failed with error code: (0x80070663), This update package could not be opened. Verify that the update package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer update package.

Workaround

Most often this happens because a patch package is missing from the Windows Installer cache and is required to install a new patch. In this case, the Windows Installer cache must be rebuilt.

While the method to determine which packages have to be restored is fairly generic, these following instructions are specific to Office to serve as an example and because this seems to be the most common case given the likely cause described in the next section, Prevention, and the size of Office 2007 SP1 patch packages.

1. Click on the link to the log file right above the line beginning with "Final Result". A file should open where the majority of lines begin with "MSI".
2. Search for "SOURCEMGMT" (without quotes). A few lines above it should note the missing package. For example (highlight added for emphasis):
   Couldn't find local patch 'C:\WINDOWS\Installer\3bb98.msp'. Looking for it at its source.
3. Search ahead from that point for "2203" or "1706" (without quotes). Note the file name within that line. For example (highlight added for emphasis):
   Note: 1: 2203 2: C:\Temp\OWP15A.tmp\MAINWWsp1.msp 3: -2147287037
4. In this example, MAINWWsp1.msp is part of Office 2007 SP1. If you find a different file name, search the web for any references to that file to determine what to download. Be sure you only download packages from their original manufacturers' web sites. In this example, download http://www.microsoft.com/downloads/details.aspx?FamilyID=9EC51594-992C-4165-A997-25DA01F388F5 to %TEMP%.
5. Open an elevated command prompt a change directories to %TEMP%:
   cd %TEMP%
6. Extract the contents of the executable package; note that the file name will differ based on the language you downloaded:
   office2007sp1-kb936982-fullfile-en-us.exe /extract:"%TEMP%\office_2007_sp1"
7. Copy MAINWWsp1.msp to the location where Windows Installer was originally looking. In this example above, that location is C:\WINDOWS\Installer\3bb98.msp. Remember that this location will vary so you need to check your log file as described above.
   copy "%TEMP%\office_2007_sp1\MAINWWsp1.msp C:\WINDOWS\Installer\3bb98.msp

Now try installing VS2008 SP1 again.

Prevention

While there are potentially other reasons packages might be missing from the Windows Installer cache in %WINDIR%\Installer, the most common cause is when those files are deleted to free up disk space. Those files directly under %WINDIR%\Installer are required for Windows Installer to function properly for all maintenance installations, which is everything after initial install including patch install, patch uninstall, repairs, changes to feature selection, and even product uninstalls. These files must not be removed.

If you need to free disk space, be sure to run the Disk Cleanup utility in your your Accessories / System Tools programs folder first. You can also uninstall old and unneeded applications.

Because Windows Installer may require a lot of space on your system drive, be sure to partition your hard disk with plenty of space not just for Windows or Windows Installer, but also because a lot of applications may install to Program Files or Common Files which are, by default, on your system drive.

Details

Windows Installer will always open every patch registered to a product whether or not it has already been obsolesced or superseded when opening a product or package handle (as long as machine state is not ignored). When performing a maintenance installation, a product is opened and all patches registered to that product are opened. If one or more of those patch packages is missing from the Windows Installer cache, Windows Installer attempts to resolve the location as you can see from the log below.

MSI (s) (D4:98) [14:17:19:688]: Opening existing patch 'C:\WINDOWS\Installer\3bb98.msp'.
MSI (s) (D4:98) [14:17:19:688]: Note: 1: 2203 2: C:\WINDOWS\Installer\3bb98.msp 3: -2147287038
MSI (s) (D4:98) [14:17:19:688]: Couldn't find local patch 'C:\WINDOWS\Installer\3bb98.msp'. Looking for it at its source.
MSI (s) (D4:98) [14:17:19:688]: Resolving Patch source.
MSI (s) (D4:98) [14:17:19:688]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (D4:98) [14:17:19:688]: User policy value 'DisableMedia' is 0
MSI (s) (D4:98) [14:17:19:688]: Machine policy value 'AllowLockdownMedia' is 0
MSI (s) (D4:98) [14:17:19:688]: SOURCEMGMT: Media enabled only if package is safe.
MSI (s) (D4:98) [14:17:19:688]: SOURCEMGMT: Looking for sourcelist for product {BEE75E01-DD3F-4D5F-B96C-609E6538D419}
MSI (s) (D4:98) [14:17:19:688]: SOURCEMGMT: Adding {BEE75E01-DD3F-4D5F-B96C-609E6538D419}; to potential sourcelist list (pcode;disk;relpath).
MSI (s) (D4:98) [14:17:19:688]: SOURCEMGMT: Now checking product {BEE75E01-DD3F-4D5F-B96C-609E6538D419}
MSI (s) (D4:98) [14:17:19:704]: SOURCEMGMT: Media is enabled for product.
MSI (s) (D4:98) [14:17:19:720]: SOURCEMGMT: Attempting to use LastUsedSource from source list.
MSI (s) (D4:98) [14:17:19:720]: SOURCEMGMT: Trying source C:\Temp\OWP15A.tmp\.
MSI (s) (D4:98) [14:17:19:720]: Note: 1: 2203 2: C:\Temp\OWP15A.tmp\MAINWWsp1.msp 3: -2147287037
MSI (s) (D4:98) [14:17:19:720]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
MSI (s) (D4:98) [14:17:19:720]: Note: 1: 1706 2: -2147483647 3: MAINWWsp1.msp
MSI (s) (D4:98) [14:17:19:720]: SOURCEMGMT: Processing net source list.
MSI (s) (D4:98) [14:17:19:720]: Note: 1: 1706 2: -2147483647 3: MAINWWsp1.msp
MSI (s) (D4:98) [14:17:19:720]: SOURCEMGMT: Processing media source list.
MSI (s) (D4:98) [14:17:25:470]: SOURCEMGMT: Resolved source to: 'MAINWWsp1.msp'
MSI (s) (D4:98) [14:18:57:126]: Note: 1: 1314 2: MAINWWsp1.msp
MSI (s) (D4:98) [14:18:57:126]: Unable to create a temp copy of patch 'MAINWWsp1.msp'.
MSI (s) (D4:98) [14:18:57:141]: Note: 1: 1708
MSI (s) (D4:98) [14:18:57:141]: Note: 1: 2729

Failing to resolve the source location for the patch, Windows Installer returns error code 1635 (ERROR_PATCH_PACKAGE_OPEN_FAILED).

Often the simple solution is to find and restore the package to where Windows Installer expected to find it in the first place: back in the Windows Installer cache under %WINDIR%\Installer. You could also put it in the other locations where you see "SOURCEMGMT: Trying source".

All files directly under %WINDIR%\Installer are required. To free up additional space as mentioned in why Windows Installer may require so much space, you can delete subdirectories under or even all of %WINDIR%\Installer\$PatchCache$, or even disable it for future patch installations but at the cost of prompts for original source in many scenarios. The baseline cache files are intended to provide a backup of baseline (ex: RTM) files so that when they are needed they are available. They are needed when applying patches containing binary delta patches to individual files (as opposed to whole-file updates, which are more common) or when uninstalling patches.

You can also try finding and uninstalling superseded patches. Superseded patches are not actually uninstalled when superseded - they just become inactive. This way when all superseding patches are removed with respect to these superseded patches, those superseded patches become active again. You can even install patches in an initially superseded state for this very purpose. I do have an example of detecting superseded patches using PowerShell with the Windows Installer PowerShell Extensions installed but there are other ways by calling the MsiEnumPatchesEx() function or the PatchesEx method for script automation in your own applications or scripts.

Setup.bin is probably not a Trojan horse

Some virus scanning application have been reporting that setup.bin is a Trojan horse containing one of the following viruses:

• Win32:Trojan-gen
• Win32:Trojan-gen {Other}
• Backdoor.Win32.VB.ffx

This file is typically installed to C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Engine\setup.bin by the Windows SDK and is actually setup.exe that has been renamed to setup.bin. This file is used when you build your own installation package that can chain install packages like .NET, Report Viewer, SQL, the VC runtime, Visual Tools for Office runtime, and Windows Installer.

Jeremy Kelley, a program manager in our Community Connections team, posted the following to an MSDN forums thread where this was reported.

Hi everyone, I know you've all been waiting anxiously for a response from us on this issue, and we appreciate your patience. Since the issue was first reported, we've been working with the AV companies to confirm the virus alert on setup.bin as a false positive.

The AV companies have all been great helping us get this resolved; with them, we are ensuring that this is properly addressed in updated virus definition files from each of the companies. While there are some scanners that are still flagging this as a virus, the majority of our partners have already updated their signatures.

For more information on which scanners have updated signatures for this, please see this site: http://www.virustotal.com/analisis/a3afa20071b67a8fa794173be1ec60d5 If you are running a scanner that is still detecting a virus in setup.bin, please watch for updated signatures from your AV vendor to resolve the issue.

Thanks to everyone who reported the issue, we appreciate the early heads up each of you have given us. I'll be around here on the thread if anyone has any other questions with this issue.

-Jeremy Kelley
Program Manager
Developer Division Community Connection Team
Microsoft

If this file was already quarantined I recommend you update your virus definitions and re-scan it. If no problems are found please restore it to its original location.

ISA Proxy Client may be required to download VS 2008 SP1

If you're on a network that uses Microsoft ISA Server or another proxy server, you may have problems downloading Visual Studio 2008 Service Pack 1. The error dialog displays the following.

The installation failed with the follow message:

Fatal error during installation.

Click the Finish button to exit.

Solution

Download and install the Microsoft ISA Proxy Client. The default settings should be sufficient, but if you have doubts or questions please contact your network administrator.

Details

The VS2008 SP1 bootstrap application relies on the Background Intelligent Transfer Service (BITS), falling back to WinHTTP then URLMon to download packages. BITS and Windows HTTP Services (WinHTTP) do not, by default, use Internet Explorer proxy settings. So even if you have Internet Explorer set to automatically detect a proxy server or have manually specified a proxy server, these protocol handlers will fail if the network administrator has enforced the proxy server; i.e., it cannot be bypassed.

These protocol handlers will attempt to automatically detect a proxy server, but if that information is not available or the system accounts were not manually configured with proxy server settings they will fail.

You can use the BITSAdmin tool to configure BITS to use automatic proxy detection or manual proxy settings like shown in the following examples.

bitsadmin.exe /util /setieproxy localsystem AUTODETECT
bitsadmin.exe /util /setieproxy localsystem MANUAL_PROXY proxy1:80 "<local>"

If BITS is not properly configured for your network proxy, you might also be getting error 0x8024402C from Windows Update.

Because BITS is robust, it is preferred to download packages for VS 2008 SP1; but if you'd like to configure WinHTTP to use the current IE proxy settings, you can use the Proxy Configuration Tool like shown in the following example.

proxycfg.exe -u

Another solution if you're on a network that uses ISA Server is to install the Microsoft ISA Proxy Client which should properly detect the proper proxy server settings and configure both the current user and machine accounts to use the correct proxy servers. If it does not, please contact your network administrator.

Updated: first reconfiguring BITS or WinHTTP to use the correct proxy is the recommended approach before installing the ISA Proxy Client. The ISA Proxy Client is only supported for ISA-protected networks. Since this problem is not limited to ISA proxies installing the ISA Proxy Client may not work on your network.

VS 2008 SP1 Beta must be removed prior to installing the release of VS 2008 SP1

When I announced that Visual Studio 2008 SP1 RTM will install over SP1 beta, we were on track to make that reality. However, when SP1 beta shipped we found that adding new components into existing features was causing a prompt for source for non-default installations of Visual Studio 2008. To fix this, we would have to remove those components and put them into a new feature. This, in turn, causes the installation to not actually update most files if the beta was installed because it advertises the features.

After a lot of discussion, we decided that because a prompt for source is a blocking issue for more customers that installed the beta we would block SP1 RTM from upgrading SP1 beta. To make this easier, we have provided a tool that uninstalls only certain beta patches. Not all patches need to be removed so this exercise is made simple and relatively faster than uninstalling all of the beta.

Note: you do not have to uninstall Visual Studio 2008 Express Editions with SP1 Beta prior to installing Express SP1 RTM. The tool described below for VS box SKUs does not apply to Express SKUs.

Workaround

If you installed VS2008 SP1 Beta, you will see a dialog similar to the following.

The dialog above lists all the pre-release updates that must first be removed, depending on which you have installed. It reads,

You must first use Microsoft Visual Studio Patch removal tool before installing Visual Studio 2008 SP1. The tool will verify Visual Studio integrity and remove previous Visual Studio 2008 updates or pre-release software

• Microsoft Visual Studio 2008 - KB945140 (Beta)
• Microsoft Visual Studio 2008 - KB944899
• Microsoft Silverlight Tools Beta 1
• Microsoft Visual Studio 2008 - KB949325

The tool is straight forward to use and should allow you to install VS 2008 SP1 - assuming you are running as an administrator and have applicable products installed.

Details

When VS 2008 SP1 Beta is installed it adds new components to existing features. This causes Windows Installer to install that feature, its parent features, and all those features' child features which follow their parent install state. If one of those features was not already installed, the files authored into that feature likely do not already exist on your machine. Windows Installer then prompts for source to find and install those files.

To fix this, we have to move those new components to new top-level features which always get installed.

Because a patch alters the view of the product - the installer package (.msi file) and all patch packages (.msp files) combined - those new components are now part of the product. When SP1 Beta is already installed and SP1 RTM is being installed, those new components in Beta get removed from their parent features and put into new features. Because a there is no "move" operation, it's actually a "delete" and an "add". Deleting a component, however, advertises the parent feature. The result is that any files within affected features are not updated because they are not registered as being installed locally. In fact, none of those files will ever be upgraded again until the product is reinstalled with a specially crafted command line specific to your machine, or uninstalled and then re-installed. That means no updates and no new features for a lot of the product.

Based on the estimated number of people that installed the beta and the number of people that customized their installations of Visual Studio 2008, we felt it was better to block installation of VS2008 SP1 RTM if VS2008 SP1 Beta was installed. We also block if features installed with applicable products are also already advertised since this could happen in a couple of other scenarios - like if KB944899 was installed and you then installed SP1 Beta.

The tool we have provided performs these same checks on product that SP1 updates and attempts to fix them. When uninstalling patches, however, you might be prompted for source to restore files in shared components. This happens when share components in another product were already updated. When any other products' shared components are then updated, those products' baseline caches are not updated with a backup copy of those shared files already updated. To streamline the operation, for one product where this happened 100% of the time we shipped the source but it was small - only a few megabytes. But for Visual Studio and other products which are much larger overall, note the title of the source prompt dialog, insert your installation media (network installs likely won't cause prompts), and browse to the path of that product. Typically this will be vs_setup.msi in the root directory for the drive containing the installation media.

Updated: added that users do not have to remove Express SP1 Beta prior to installing Express SP1 RTM.

Visual Studio 2008 Service Pack 1 Released

Microsoft .NET Framework 3.5 Service Pack 1, Visual Studio 2008 Service Pack 1, and Team Foundation Server 2008 Service Pack 1 have been released. This is a big release on the heals of SQL Server 2008 which has a dependency on .and includes NET Framework 3.5 SP1.

This is a big release with many new features and improvements over previous releases. The service pack package itself has undergone a number of significant changes including a web bootstrap that downloads only the updates you need on your system and splits up larger patch packages into smaller packages that install together in a single transaction. For example, the default installation installs only VC libraries and tools for x86 so the patches which contain x64 and IA64 libraries and tools are not downloaded and applied. If you later install those features, re-run SP1 to update them.

There are a lot of updates and new packages. There are 5 update executables (.exe files), 4 installer packages (.msi files), and 13 patch packages (.msp files) per supported language. The executables actually contain a mix of installer and patch packages, including the .NET Framework 3.5 SP1.

If you're having problems installing NetFX 3.5 SP1, VS 2008 SP1, or TFS 2008 SP1 please be sure to run the log collection utility available for download. If you're installing VS2008 SP1 you will find an HTML log file in your %TEMP% directory with a name matching the pattern Microsoft Visual Studio 2008 SP1_*.html. When you open this file, the error will be displayed. With Internet Explorer you may need to first click the action bar that reads, "To help protect your security, Internet Explorer has restricted this webpage from running scripts or ActiveX control that could access your computer. Click here for options...". There is a lot of rich information in this log, and it links to other files containing more detail that have the same file name with the .txt extension.

Please watch here for more news about and support of SP1.

Why Windows Installer May Require so much Disk Space

Windows Installer is an engine for performing transactional installations. When installing a product for the fist time, most often few or no files to be installed are already present on the machine. But when upgrading or patching a product, most often those files are replaced so copies must be kept if an error occurs and the installation needs to roll back. The following describes where and why Windows Installer may require so much disk space.

Extracted files

A bootstrap application may be required for a number of reasons. A bootstrap application may compressed setup files into the bootstrap application, or they might all be included in a self-extracting archive. Bootstrap applications may also download files from a web site either directly to a location on disk or indirectly to the Internet files cache.

This location is typically under %TEMP%.

If the extractor did not delete these files, you can delete these files after installation has completed. Note that some installers may register these files as a source cache. If the source cache is deleted and source is required for any reason, Windows Installer may prompt for the installation source or simply fail to reinstall the product.

Temporary local copy

If a full user interface is authored in a package and is to be displayed, Windows Installer creates copies of the .msi or .msp files in the user's %TEMP% directory. If this portion of installation - the client installation - was elevated, the %TEMP% location is for the user who authenticated and authorized the installation. Windows Installer uses this copy for initial disk space costs and through the UI phase until the installation script is to be generated.

This copy is in addition to any temporary copy that might have been extracted to the local hard drive. That is, the package that is referenced using msiexec.exe or in a Windows Installer API call is copied to %TEMP% with a Windows Installer-generated file name even if the source copy already was in %TEMP%.

This location is under %TEMP%.

If Windows Installer did not delete these files, you can delete these files after installation has completed.

Package cache copy

Whether or not a user interface is displayed, the primary portion of the installation - the only portion that should attempt to modify machine state - runs as a service. At this point, the package - either a .msi file stripped of any embedded cabinets, or an entire .msp file - is copied to the Windows Installer cache under %WINDIR%\Installer. If the installation is successful, this file will remain in that location for all future maintenance installations including uninstalling the product. Patch packages are cached in whole to make available any updated files for future maintenance installations like repairs or installing additional patches.

This location is under %WINDIR%\Installer.

These files cannot be deleted or future maintenance installations on products - including even uninstalling a product - will fail.

Installation scripts

There are two primary phases for Windows Installer: generate an installation script, then execute the installation script. But because Windows Installer is a transactional installation engine, unless rollback is disabled using either the DISABLEROLLBACK property or DisableRollback system policy a second script for rolling back the installation is generated.

These scripts contain all the operations that Windows Installer will perform when the script is executed. The rollback script is essentially those operations in reverse order. These scripts can grow quite large and are typically dependent on the overall size of a product. As an optimization, Windows Installer will typically not repeat file system directory and registry keys but will instead call SetTargetFolder or RegOpenKey opeations respectively, which set the scope for subsequent file or registry value operations. Custom actions can schedule similar operations to reduce disk space as well.

These scripts are created in C:\Config.Msi where C: is the fixed drive with the greatest amount of space available and is not necessarily the system drive.

These scripts must not be deleted. Windows Installer will delete them when an installation completes, even if an installation spans multiple reboots.

Destination files, registry values, and other reserved space

When the installation script is executed, if any files are to be copied or registry values written these resources will require space on the hard drive. Windows Installer will calculate how much space is required when the CostFinalize action is executed.

These resources are located wherever authored or the end user selected as the target location.

These resources should not be deleted; they comprise the product that has been installed and will likely prevent the product from starting up or functioning correctly. If any resources are deleted, you can repair the product from Add or Remove Applications control panel applet.

Copies of files for rollback

Because Windows Installer is a transactional installation engine, when existing files will be overwritten Windows Installer creates backup copies of those files. These files are created in a temporary directory along with the installation scripts. They are not compressed and will require as much space as those files required before being updated. Rollback files are more commonly created when products are patched, but are not limited to patch installation. Any product can upgrade files for another product, and should do so as shared components.

These resources are copied to C:\Config.Msi where C: is the fixed drive with the greatest amount of space available and is not necessarily the system drive.

These files should not be deleted. Windows Installer will delete them when an installation completes, even if an installation spans multiple reboots.

Baseline cache for patching and patch removal

Windows Installer 3.0 added support to uninstall patches and to provide a more robust experience for applying binary deltas to existing files without accounting for every possible state an existing file could be in. That is, if a patch were to update foo.dll v1 to foo.dll v2 using a binary delta applied to foo.dll, the patch would have to account for foo.dll v3 or even having been updated by another product installation, or the installation would fail.

To make either of these features possible, Windows Installer copies files to be updated to the baseline cache under %WINDIR%\Installer\$PatchCache$ for each product. At most, there might be two copies of files created since Windows Installer retains a copy of the original (RTM) file and the latest minor upgrade (often distributed as "service packs") when either version of a file is initially replaced.

Since Windows Installer only copies a file to be updated to the baseline cache if the file will be overwritten, a baseline cache for a file might only exist for one product even if updated by a patch for multiple installed products. This can lead to source media requirements when some products are updated. Windows Installer 4.5 provides a feature to fix this by copying shared files to all products' baseline caches that installed those files - thus increasing disk space consumption. This improves servicing scenarios but at the cost of additional disk space.

These files are located under %WINDIR%\Installer\$PatchCache$ in a per-product location.

These files can be deleted or the baseline cache disabled using the MaxPatchCacheSize policy but when uninstalling a patch or when restoring missing files you will be prompted for source if a user interface is displayed; otherwise, the installation attempt will simply fail.

Enable BITS Logging

Microsoft Visual Studio 2008 Service Pack 1 uses a new bootstrap application that chains several packages together for a seamless installation experience. Because VS2008 SP1 contains a lot of fixes and new features, it is also quite large - almost 3 times as large as VS2005 SP1.

To download all this data, we use the Background Intelligent Transfer Service, or BITS, first and foremost. To help diagnose failures with BITS that results in falling back to other download mechanisms which may also fail, please enable BITS logging using the script StartBITSLogging.cmd available from here and attached to this post. This script enables logging to %WINDIR%\System32\bits.log. Be sure attach this file to any bug reports filed on Microsoft Connect for Visual Studio.

Windows Installer 4.5 is Now Available

Windows Installer 4.5 is now available on the download center for a variety of platforms, including Windows XP SP2 and newer, Server 2003 SP1 and newer, and both Vista and Server 2008 RTM and newer.

The Windows Installer 4.5 SDK is also available as a separate download, and the documentation has been updated on MSDN as well. You might noticed that the SDK installation package has a familiar red motif.

If you participated in the betas, you might have noticed some changes to new features since Beta 1. The CustomAction table has a new column, ExtendedType - an I4 that currently supports msidbCustomActionTypePatchUninstall (0x0800). There's also been some bug fixes over past versions including 4.0 on Vista and Server 2008.

KB944899 Should be Removed before Installing Visual Studio 2008 SP1

Before installing Visual Studio 2008 Service Pack 1, you should first uninstall KB944899, a hotfix which improves performance when stepping through source downloaded from a source server.

If KB944899 is not removed prior to Visual Studio 2008 SP1, sometime during the middle of installation an error will occur and the error dialog is displayed as shown below.

Click on the "log file" link in the middle of the dialog. If it opens in Internet Explorer, you may have to click on the yellow information bar that appears on the top to allow scripts to run. Check the "Errors" message type and the following errors are highlighted.

Action: Install patch (C:\Users\heaths\AppData\Local\TEMP\VS90sp1-KB945140-X86-ENU.msp) to Microsoft Visual Studio Team System 2008 Team Suite - ENU
Returning IDOK. INSTALLMESSAGE_ERROR [You must first uninstall the update for KB944899 before this installation can continue]
Patch (C:\Users\heaths\AppData\Local\TEMP\VS90sp1-KB945140-X86-ENU.msp) install failed on product (Microsoft Visual Studio Team System 2008 Team Suite - ENU). Msi Log: Microsoft Visual Studio 2008 SP1 (Beta)_20080516_110428247-MSP0.txt
MsiApplyMultiplePatches returned 0x643

How to workaround this issue

You should remove KB944899 using the following instructions.

Download and run the cleanup tool

Updated: Download and run the cleanup utility which will both uninstall the patch if installed and delete any relevant traces in the registry. This is the recommended approach which supersedes the following manual instructions.

Windows Vista and newer

1. Open Control Panel
2. Click on "Programs"
3. Click on "View installed updates"
4. Remove KB944899 listed under any versions of Visual Studio 2008, ex: "Hotfix for Microsoft Visual Studio Team System 2008 Team Suite - ENU (KB944899)"
5. If any other patches are installed on Visual Studio 2008, proceed to "Registry cleanup" below.

Windows XP and Server 2003

1. Open Control Panel
2. Click on "Add / Remove Programs"
3. Check "Show updates"
4. Remove KB944899 listed under any versions of Visual Studio 2008, ex: "Hotfix for Microsoft Visual Studio Team System 2008 Team Suite - ENU (KB944899)"
5. If any other patches are installed on Visual Studio 2008, proceed to "Registry cleanup" below.

Registry cleanup

Newer patches may write the detection data for KB944899 as a mean for detecting hotfixes, so you may need to delete a registry key to prevent VS2008 SP1 from blocking the installation.

1. Open an elevated command prompt
2. Type the following command to determine if any other references to KB944899 are registered
   reg.exe query HKLM\Software\Microsoft\Updates /f KB944899 /k /s
3. For each search result displayed, copy the full key name including spaces and run the following command to delete the key; replace registry key below with the actual registry key included in quotes
   reg.exe delete "registry key" /f

Description of the issue

The original release of KB944899 added new components into existing features which, though documented as supported, forced those features and their feature trees to be installed. If one or more of those features were not installed on a machine, Windows Installer then prompted for source or simply failed during silent installations. Source is required for the files in those features to be installed.

The current download for KB944899 - a new revision - works around this problem and will not block SP1 but many customers already have the original release of KB944899. To prevent prompting for source and installing features not originally selected for installation based on user preference, VS2008 SP1 will block if the original release of KB944899 is installed or appears to be installed.

KB944899 might also appear to be installed because another update might include the same fixes. In this way, older detection code continues to work with the detection keys when a newer update is installed with the same fixes. This is normally beneficial to deployments that require a specific hotfix to be installed even years after the hotfix was released.

The Release of Visual Studio 2008 SP1 will Install over SP1 Beta

One of many improvements made to Visual Studio 2008 Service Pack 1 is that VS 2008 SP1 Beta customers will not need to uninstall SP1 Beta before installing the release of SP1. The same is true for Visual Studio 2008 Express products and .NET 3.5 SP1 - both of which are complete upgrades to older products that may already be on the system or that can be installed on a clean system.

So please read the requirements and known issues, give Visual Studio 2008 SP1 Beta a try, and provide feedback about we can improve the release of VS2008 SP1 and future releases.

How to Download all of Visual Studio 2008 SP1

Visual Studio 2008 Service Pack 1 is comprised of multiple packages, including executables, installer packages, and patches. Compare this with Visual Studio 2005 SP1 which was a single patch wrapped in an executable. A lot of updates were made to both the .NET Framework and VS 2008 - along with changes to SQL and other bits from across the company - so a download manager was created to download only what you need.

But if you want to put VS 2008 SP1 on your network or a DVD for later or continued use, you can pass /createlayout to the download bootstrap application. The /createlayout parameter requires an argument to specify the directory to download to.

VS90sp1-KB945140-ENU.exe /createlayout \\server\share

After a brief moment, the following dialog is displayed.

This will download all the packages for a single language of VS2008 SP1 and will put an executable named SPInstaller.exe into that same directory. You'll need about 782MB free for SP1 Beta. Run SPInstaller.exe to install the service pack from that install point. SPInstaller.exe will first use valid packages in the same containing folder before fetching them from the Internet.

There is a known issue that .NET Framework 3.5 SP1 requires an active connection when installing the layout. This is because only the web bootstrap application is downloaded. For VS2008 SP1 Beta, you can work around this by downloading the full redistributable and replacing dotnetfx35setup.exe in the layout folder where you saved the rest of the downloaded files. Note that the package you download will be dotnetfx35.exe, so you'll need to rename it to dotnetfx35setup.exe. Just selecting the existing dotnetfx35.exe file in the Save As dialog will do this automatically.

Changes for Microsoft Visual Studio 2008 Service Pack 1

Microsoft Visual Studio 2008 Service Pack 1 (Beta) has been released to web, along with Microsoft .NET Framework 3.5 Service Pack 1 (Beta). Included as part of .NET 3.5 SP1 are Microsoft .NET Framework 2.0 Service Pack 2 (Beta) and Microsoft .NET Framework 3.0 Service Pack 2 (Beta).

Visual Studio 2008 SP1 includes over 250 new features and improvements to existing features, including SQL Server 2008 support. .NET 3.5 SP1 also includes many new features on which VS 2008 SP1 is dependent. Because of this, VS 2008 SP1 chains .NET 3.5 SP1 and other necessary components as you can see from the partial list in the screenshot below.

This means the complete download for VS 2008 SP1 is large - almost twice as large as VS 2005 SP1. The full beta download is about 761 MB which contains the 229 MB full redistributable for .NET 3.5 SP1. However, because of changes we made for VS 2008 SP1 the patch installs in about half of the average time it took for VS 2005 SP1. In addition, we made some additional changes we're sure you'll like.

Smaller Individual Packages

Visual C++ libraries and headers comprised almost 70% of Visual Studio 2005 SP1 and because it was all in a single patch package, everyone had to download it. However, libraries and headers for x64 and IA64 are not installed by default and some customers may not install VC++ at all if they only focus on managed languages such as VB or C#. To save time space, three separate packages are produced for each of x86, x64, and IA64 which contain the libraries and headers for VC++. If you don't have all the VC++ features installed, only part of the overall patch release is downloaded. This does mean, however, that if you later install VC++ features you will need to reinstall SP1 again in order to download and apply the separate patches.

Also by reducing the size of the patch packages, many more customers will be able to install successfully without seeing another 1718 error message stating that the patch was rejected by digital signature policy.

Single Installation Experience

Even though Visual Studio 2008 SP1 includes multiple packages - and not just for Visual Studio - a single user interface using the typical wizard style provides download and installation progress as you see below.

VS2005 SP1 only had a chainer to make sure the patch was correctly applied to each applicable and installed product, but did not implement an external UI handler that provided a consistent and uninterrupted user interface. As a result, some customers canceled dialogs under the assumption that VS2005 SP1 was simply installing again and their machines were not updated fully, sometimes leading to destabilization of Visual Studio 2005.

Friendly Logging

Windows Installer logs are difficult for many to read, so the new external UI chainer generates an HTML log file. Script is embedded in the HTML log to provide filtering mechanisms, but by default the error is displayed. Paths to the MSI logs are also provided in the HTML log to diagnose specific installation problems.

Express SP1 are Major Upgrades

Visual Studio Express products are intended to be downloaded quickly. But VS2005 Express SP1 customers had to download both Express RTM and the appropriate SP1 package that was about the same size resulting in a download and install time of almost twice as long. For VS2008 Express products, customers can simply download Express SP1 whether they have Express RTM installed or not. The product will be upgraded if present in roughly the same amount of time as it takes to install the product fresh. The big advantage for new customers is that they only need to download and install a single package.

Known Issues

For a complete list of known issues, please read the Visual Studio 2008 SP1 Beta Readme.

Silverlight 2 Tools Beta 1 Must be Uninstalled

Before VS2008 SP1 can be installed, Silverlight 2 Tools Beta 1 must be uninstalled. This includes both "Silverlight Tools Beta 1 for Visual Studio 2008" and KB949325. You do not need to remove the Silverlight 2 runtime.

Microsoft .NET Framework 3.5 SP1 Fails to Install

As part of the .NET 3.5 SP1, .NET 2.0 SP2 is installed. A problem occurs on some customers machines due to registry corruption or missing files that prevents 2.0 SP2 from installing which will fail 3.5 SP1. If you run into problems installing 3.5 SP1, please read through KB951950.

Your Machine must be Upgraded Completely

Because a large number of files are shared between products being upgraded, Service Pack 1 must be installed on every applicable product installed on your machine or none of them may work correctly. This means if you have Visual Studio and Express installed, you must download the appropriate updates for each and install them.

Upgrades Must be Uninstalled Individually

For reasons that I'll go into in a future post, we do not provide a uninstall chainer. That is, in order to uninstall SP1 and return your machine back to an RTM state, you must go through Add or Remove Programs and uninstall the service pack components individually. If you have both Visual Studio and Express installed, you may have to uninstall both Express SP1 and Visual Studio and reinstall both at the RTM level again.

Feedback

To provide feedback on the SP1 installation experience or changes to Visual Studio 2008 or Express made by SP1, please visit our forums.

Visual Studio and .NET Log Collection Utility

Setup and deployment is a tricky business. Machines can be in many different and often unforeseen states that cause setup to fail. But rarely will setup actually crash, and that is why setup logs are vital to diagnose install, repair, and uninstall problems.

Setup applications for Visual Studio and .NET may write to many different logs because the products are actually comprised of many different packages. Aaron Stebner had documented several log file names for Visual Studio 2008, but with our new and improved patch wrapper we may write even more log files. As we onboard new CTPs for great new features in Visual Studio the list of log files may also grow.

So our QA team has written a tool to collect all these logs for VS 2005 and 2008, and .NET 2.0 through 3.5 aptly named, collect.exe. The link below is an updated version of the old collect.exe that you should use when reporting bugs with setup.

Using the Collect Utility

If you encounter any setup issues, we will need all relevant logs. Please follow the instructions below to collect all those logs.

1. Download collect.exe from the link  below.
2. You may choose to save the tool for later use, or to run directly.
3. The utility creates a compressed cabinet of all the VS and .NET logs to %TEMP%\vslogs.cab.

Reporting Setup Errors

There are several options for reporting setup errors, but you might consider first checking to see if the issue is a known issue. This will save you time and provide more immediate results. In most scenarios, there will be a link on the error page after setup completes. Clicking on this should provide a smaller log that highlights the errors encountered. To dig deeper, check out some of the tips provided on Aaron's blog and on my blog.

If you would like to report an error, be sure to collect logs as described above and choose from the options below.

1. Search or post on MSDN Forums in .NET Framework Setup or Visual Studio Setup and Installation. This is a community-driven web site on which Microsoft employees also participate.
2. Report installation issues or provide feedback for Visual Studio on Microsoft Connect. You may upload logs using Connect. This allows us to view and manage bugs, and customers to vote or provide additional details in a consistent manner.
3. Upload logs using Windows Error Reporting. Both the MSDN Forums and Microsoft Connect will most often provide faster help.

MSIZap is not Uninstall

The tool msizap.exe that is available in the Windows SDK and elsewhere on the web (remember to always download from a trusted source) is a powerful but dangerous tool that is often used to quickly and casually, and can leave your machine in a corrupted state if not used correctly. The same is true for the Windows Installer CleanUp Utility which uses msizap.exe.

Windows Installer is a transactional, data-driven deployment technology used by most of the products deployed on Windows platforms today. At its core, it is a loose referential database that describes software applications and that information can be updated by changes, or transforms. That package may describe files, registry values, assemblies, and even custom data that is acted upon by the engine by first generating a script and then executing it. One of the final typical actions of this script is to register product and patch information so that it is cataloged and can be queried; and so that Windows Installer itself can perform future maintenance installations which includes updates and uninstalls.

Updates are supported by actions that first remove older data and then install the newer data. An uninstall essentially skips the install actions. That means, then, that files, registry values, assemblies, and custom data is simply removed.

With that in mind, msizap.exe merely removes the product registration information from the registry and optionally files in the Windows Installer cache - a critical set of files that is necessary for future maintenance installations including proper uninstalls. Removing files from your Windows Installer cache can cause products like the Microsoft .NET Framework 2.0 Service Pack 1 to fail to upgrade older versions.

Msizap.exe is not magic, but merely a tool that acts only on Windows Installer registration data. It will not run the removal actions. So, for example, if you zapped the entire .NET 2.0 RTM products instead of just certain patches, actions that unregister WMI providers incompatible with .NET 2.0 SP1 would not run and, therefore, would not remove the WMI provider registration. In addition, files and other registry data is not removed so the .NET Framework is not truly removed from the system. Msizap.exe is no more of an uninstaller than simply forgetting that a program is installed, which is all it basically causes the Windows Installer engine to do.

Msizap.exe is an effective tool when product registration is already corrupt for whatever reason; however, it should only be used as an absolute last resort. Always try to uninstall a product first through the Add/Remove Programs control panel or the Software Explorer for newer Windows platforms like Vista. If you cannot see the product listed in the control panel, see if there is an "Uninstall" icon or similar in your Start menu for that program group. If you don't see such an item, search the web for what other people have done to uninstall a product. For Windows Installer products, by knowing certain data you can always uninstall from the command line using msiexec.exe. To help diagnose issues properly, always generate a log by passing /L*vx uninstall.log to the command line to msiexec.exe. In this log will almost always be the answer to determine what is wrong so that a product can be properly uninstalled.

For help uninstalling a product when errors are encountered, Aaron Stebner's and my blog can be helpful most often for Visual Studio and .NET installation problems. At times, they may even help in general since problems like registration or cache corruption can happen to any product - especially if msizap.exe was already used improperly. You can also search for error strings you find in the Windows Installer log files which are most often right after the string "Return value 3". The error message number like 1714 you will see is more helpful than a return code at the end of a log like 1603 (0x643).