Hey all,

I'm happy to report that the official released version of the Windows XP Embedded SP2 update is now available for download!!  You can go to http://go.microsoft.com/fwlink/?linkid=38214 to be redirected to the official download page now!

Windows XP Embedded SP2 has lots of bug fixes and quite a few new and improved features:

1. All of the desktop Windows XP features for enhanced security (no execute support, improved firewall, security center, and on and on)
2. All of the XP Embedded SP1 QFEs
3. Many updates to Enhanced Write Filter - hibernate-once, resume-many (HORM), ability to commit and disable without a reboot for RAM overlays, ability to commit individual files with the EWF APIs, much better error handling
4. Bluetooth support
5. Other updated components such as the .NET Framework 1.1 SP1 (included in the value add folder, you have to install it separately) and DirectX 9.0
6. Huge updates to the documentation including full component help, many more end-to-end how to scenarios, full documentation for all new SP2 features and bug fixes - you will notice several doc updates even when comparing to the tech preview from October
7. New since the tech preview - a macro component called the Generic Device Driver support component - with this you can add all of the in-box drivers for specific classes of hardware without going through and manually adding them
8. SP2 requires SP1 to be present before you can install (it is an update to SP1), but it can be uninstalled so you can return to an SP1-level database if you need to without doing a full uninstall and reinstall
9. Other updates that I know I'm forgetting currently

Mike Hall and I have updated the web download tool since the October SP2 Technology Preview with a lot of bug fixes (mostly related to better handling of failed and cancelled downloads, plus we added a feature to start over where we left off if you close and reopen the downloader application).  Also, we integrated the ability to download MUI packs for Windows XP Embedded (currently only 6 languages are available but the other Windows XP languages will be available soon).  Just like before, please send me comments or email me directly at aaronste (at) microsoft (dot) com if you have any comments, questions or bug reports about Windows XP Embedded SP2 or the web download application.

Hey all, I have been meaning to take some time to write down some comments and strategies about unattended installation of the various pieces of Visual Studio .NET.  For this article I'm going to focus on a specific request that I've seen very often - how to chain the unattended installation of the Visual Studio prerequisites, the main Visual Studio bits and the MSDN help documentation.

In order to perform any unattended installs there are a couple of key points to remember:

• You have to create an unattended INI file that is fed into setup later on to perform the actual installation
• In order to create an unattended INI file for the Visual Studio setup package, you first have to install the .NET Framework (or the entire set of VS prerequisites) on the machine you create the INI file on - this is because the .NET Framework needs to be present in order to correctly parse and evaluate the vs_setup.msi (because vs_setup.msi contains assemblies and the mechanism Windows Installer uses to manage installation of assemblies is through fusion and fusion is installed by the .NET Framework)
• The unattended INI file is OS-specific.  That means if you create the INI file on Windows XP, you need to install Visual Studio on only Windows XP operating systems.
• The unattended INI file is also Visual Studio edition specific.  That means that you have to create the INI file using the same exact version of Visual Studio as you want to deploy (for example the English version of Visual Studio .NET 2003 Enterprise Architect)

Here are the steps I used to successfully create INI files and install Visual Studio .NET 2003 Enterprise Architect English on Windows XP Professional:

1. Run [Prerequisite Disk Path]\setup.exe /createunattend c:\prereq.ini /vsupdate="[Visual Studio Disk Path]\setup\setup.exe" /vsupdateargs="unattendfile c:\vs.ini"
2. Install prerequisites on your test machine
3. Run [Visual Studio Disk Path]\setup\setup.exe /createunattend c:\vs.ini /vsupdate="[MSDN Path]\setup.exe" /vsupdateargs="qn"
4. Open c:\prereq.ini, go to the [PostSetupLaunchList] section and change """unattendfile c:\vs.ini""" to /unattendfile c:\vs.ini
5. Open c:\vs.ini, go to the [PostSetupLaunchList] section and change """qn""" to /qn
6. Go to a clean machine without Visual Studio .NET 2003 installed and run [Prerequisite Disk Path]\setup.exe /unattendfile c:\prereq.ini

In the above instructions, the disk paths in square brackets should be substituted with the actual paths of the parts of the product in question.  Also, it is required that your computer be able to access the installation paths represented by [Prerequisite Disk Path], [Visual Studio Disk Path] and [MSDN Path] during the installation process.  Installing via CD will not work correctly because unattended install does not show disk prompt dialogs, plus that would defeat the purpose of an unattended install anyways.  I recommend following the steps in the readme on the root of Visual Studio Disk 1 to stage all of the parts of Visual Studio to a network share.  You can find the instructions for doing this for Visual Studio .NET 2003 at http://support.microsoft.com/default.aspx?scid=fh;en-us;vsnet11&x=12&y=15#installingnetwork

As always - please let me know if you have any questions with any of the above or run into trouble getting the steps to work.

Hey all, here is an interesting article from someone trying to use enhanced write filter (EWF) on top of the desktop version of XP Pro.  I can't advocate doing this because I'm pretty sure there are licensing restrictions preventing it plus there are no official tools or processes to enable it in a supported way, but I thought it was an interesting experiment - http://www.mp3car.com/vbulletin/showthread.php?threadid=37078

Hey all, I found a really useful reference on the Sysinternals website today that describes all of the available boot.ini switches that can be used.  I had no idea there were so many.  The interesting ones that I use most often in my day-to-day work are the /debug switch to enable kernel debugging, the /maxmem switch to allow simulation of low memory conditions and the /rdpath switch to boot from an SDI file.  You can find the complete reference at http://www.sysinternals.com/ntw2k/info/bootini.shtml

I have posted a couple of previous items about .NET Framework 1.0 SP3 and 1.1 SP1 installation issues (at http://blogs.msdn.com/astebner/archive/2004/09/20/232236.aspx and http://blogs.msdn.com/astebner/archive/2004/09/21/232653.aspx).  There is a KB article in the works with more information but it appears to not be posted for viewing yet, so I wanted to include the info that it contains here in the hopes that it might help some folks who are stuck installing one of these .NET Framework service packs.

.NET Framework SP Setup Issues

Overview

This document provides a reference to common setup issues and workarounds for .NET Framework 1.1 Service Pack 1 (SP1) and .NET Framework 1.0 Service Pack 3 (SP3).

Windows Update Failures

Windows Update Failed – Detailed Error Code “E0434F4D”

0xE0434F4D (-532459699) is a generic COM exception.  This is caused by a failure in the managed patch wrapper.  There are 3 recommended steps that may fix this problem.  If these do not work, further investigation will be required.

1.                  Repair .NET Framework 1.1 RTM (click Start, click Control Panel, click Add or Remove Programs, click Microsoft .NET Framework 1.1, click “Click here for support information”, click the Readme link).  This page has the 4 steps you will need to run to repair the .NET Framework

2.                  Clear the Windows Update temporary downloads cache.  See http://support.microsoft.com/kb/193385 for more information.

3.                  Clear the temporary directory.  Click Start, click Run, type “%temp%”, click Ok.  An Explorer window will open.  Select all of the files, and hit the delete key.

If these steps do not solve the problem then more information must be gathered.  To see a more detailed error, download the service pack from http://download.microsoft.com/ and then double-click the EXE package.  If the issue occurs again, a crash dialog will be displayed this time.

Windows Update Failed – Detailed Error Code “643”

0x643 = 1603 = ERROR_INSTALL_FAILURE.  This error can be caused by one of the issues listed in the Error Dialogs section below.  The two most likely causes are the netfx.msi resolve source issue or the info 9002 issue.

To see a more detailed error, download the service pack from http://download.microsoft.com/ and then double-click the EXE package.  If the issue occurs again, an error dialog will be displayed this time.

Windows Update Failed – Detailed Error Code “652”

0x652 = 1618 = ERROR_INSTALL_ALREADY_RUNNING.  This error is caused by the item titled Windows Installer Error 1618 – Another installation is already in progress described below.

Crash Dialogs

TargetInvocationException in SLxxx.tmp – missing registry key

TargetInvocationException in SLxxx.tmp can occur for many different reasons.  One of the reasons that this crash occurs is when the Windows Installer registry hive is missing the LocalPackage value for the version of the .NET Framework being serviced. 

Use the registry editor (regedit.exe) to navigate to

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData.  Next, search for the string “.NET Framework”

When the search completes, several registry name/value pairs will be listed in the right-hand window pane.  If a DisplayName value of “Microsoft .NET Framework” exists but there is not a LocalPackage value then the TargetInvocationException is being caused by this issue.

Reinstalling .NET Framework 1.0 or 1.1 will fix this problem. 

TargetInvocationException in SLxxx.tmp – missing MSI file

Another variation of the TargetInvocationException error is caused by a missing cached MSI file in the %windir%\Installer directory.  This crash occurs when the Windows Installer registry hive contains a LocalPackage value that points to a nonexistent file.

See the previous topic (TargetInvocationException in SLxxx.tmp – missing registry key) for details on how to find the LocalPackage registry value.  Once the key is found open a command prompt (click Start, click Run, type cmd) and use the dir command to try to locate the target of the LocalPackage value.  For example, if the LocalPackage key was d:\windows\installer\f493a.msi you would type “dir d:\windows\installer\f493a.msi”.  If the dir shows “file not found” then the TargetInvocationException is being caused by this issue.  Reinstalling the .NET Framework 1.0 or 1.1 will fix this issue. 

If the file does exist then the TargetInvocationException is being caused by another issue. 

TargetInvocationException in SLxxx.tmp – virus scanner

A TargetInvocationException can occur if the service pack setup “cancel” button is pressed while a virus scanner is running.

In this scenario, the TargetInvocationException appears right before the success dialog is displayed and does not harm the computer.  This TargetInvocationException can be ignored.

TargetInvocationException in SLxxx.tmp – low system resources

A TargetInvocationException can occur when the system is out of memory.

Rebooting the computer and then re-running the service pack setup can correct this problem.

SLxxx.tmp – Configuration Error

The error "Configuration Error: Unable to load JIT compiler (MSCORJIT.DLL) File may be missing or corrupt.  Please check your setup or rerun setup!" is a known issue with the setup for both the .NET Framework 1.1 SP1 and .NET Framework 1.0 SP3 releases.  The error is harmless and does not damage the machine.  On heavily loaded machines (machines in which it takes at least 5 seconds for setup to launch), before setup has begun installing, a dialog can be displayed that warns about an issue with any one of the following files:

1.                  fusion.dll

2.                  mscorjit.dll

3.                  mscorlib.dll

4.                  mscorsn.dll

5.                  mscorwks.dll

6.                  perfcounter.dll

7.                  corperfmonext.dll

8.                  aspnet_isapi.dll 

The workaround is to reduce the load on the machine by closing applications before re-running setup. 

SLxxx.tmp – Unable to Locate DLL

This dialog is a variation of the SLxxx.tmp – Configuration Error issue described above.

SLxxx.tmp – Common Language Runtime Debugging Services

This crash dialog can be displayed for many reasons. A list of known causes and workarounds follows.

·         Check the My_Computer_Zone has FullTrust permissions enabled

1.       Click Start, Control Panel, and open Administrative Tools.

2.       Select the latest version of the Microsoft .NET Framework Configuration tool.

3.       Drill-down to Runtime Security Policy, Machine, Code Groups, All_Code, My_Computer_Zone.

4.       Right-click on My_Computer_Zone, select the Permission Set tab, and verify/change the permission set to FullTrust.

Installation Hangs

Service Pack installation hangs while running IIS

The service pack installation may hang due to unresponsive IIS services on the machine (specifically WS3SVC and SMTP).  This is because setup attempts to stop some services if they are running on the machine before patching.

If the service pack installation repeatedly hangs then the workaround is to manually stop the WS3SVC and SMTP services before running setup using the following steps:

1.       Run "%SystemRoot%\system32\services.msc /s" to start the Services Manager

2.       Find World Wide Web Publishing Service (WS3SVC) and Simple Mail Transfer Protocol Service (SMTP) in the services list.

3.       Right-click on each service name and select Stop

Alternately, turning off IISADMIN by opening a cmd prompt and running net stop /y iisadmin will also solve this service pack installation hang issue.  Both WS3SVC and SMTP are dependent on IISADMIN, so stopping IISADMIN will also stop WS3SVC and SMTP.

After the installation, rebooting the computer or restarting the services by clicking "Start" instead of "Stop" in the Services Manager will return the computer to its original state.

Error Dialogs

Windows Installer Error 1618 – Another installation is already in progress

Another installation is already in progress. Only one Windows Installer setup can run at a time.  You should complete the other installation before proceeding with this install.

Windows Installer Dialog – cannot find ‘netfx.msi’

Windows Installer may display a dialog asking the user to provide the location of netfx.msi.  This is called a Resolve Source Dialog.  Sometimes patches can prompt for the original installation media (asking the user for the location of netfx.msi).  This can happen when Windows Installer determines that the original product has missing or corrupt files which are not included in the patch package. 

Repairing or reinstalling the original product will fix this issue.  Here are the repair instructions for .NET Framework 1.0 and 1.1:

Info 9002: .NET Framework 1.1 Service Pack 1 (SP1) cannot be installed

The dialog “Info 9002: .NET Framework 1.1 Service Pack 1 (SP1) cannot be installed because you have one or more hot fixes installed.  Remove them and try again” is displayed when a blocking hot fix is already installed on the computer. 

The 2003 October SDK Documentation Update (KB 827821) as well as two other .NET Framework 1.1 SDK patches (KB 841510 and KB 823641) can block the installation of .NET Framework 1.1 SP1.  A workaround for this issue is to remove all of the following registry keys:

·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M827821

·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M8278211028

·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M8278212052

·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M8278211042

·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M8278211036

·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M8278211031

·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M8278211041

·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M841510

·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M823641

Removing the registry keys can be done by using the registry editor:

1.       Click Start -> Run, type “regedit.exe” and click OK

2.       Inside the Registry Editor, navigate the registry structure until you are in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1

3.       Expand the registry key list by clicking the plus ‘+’ sign next to the ‘1.1’ registry hive

4.       Right-click on ‘M827821’ and select ‘Delete’

5.       Continue right-clicking and selecting ‘Delete’ for M827821028, M827822052, M827821042, M827821036, M827821031, M827821041, M841510 and M823641 if they are present

Windows Installer Error 1325 – ‘XXX’ is not a valid short file name

Windows Installer Error 1325 occurs when the service pack is deployed with the command line argument SHORTFILENAMES=1.  A transform file (.MST) is needed to update the short filename in the file table of the .NET Framework netfx.msi to fix this issue if it is necessary to use the SHORTFILENAMES parameter to deploy the service pack.

Windows Installer Error 1642 – The installer cannot install the upgrade patch

 “The installer cannot install the upgrade patch because the program being upgraded may be missing or the upgrade patch updates a different version of the program. Verify that the program to be upgraded exists on your computer and that you have the correct upgrade patch.”

This dialog means that the wrong patch is being run.  This happens when the wrong version of the patch is accidentally downloaded.  For instance, .NET Framework 1.0 English (ENU) is installed but the .NET Framework 1.0 SP3 German (DEU) patch is being double-clicked.

Verify that the correct patch is being used.  The patch file name ends with the 3-letter language identifier (for instance –enu or –deu).

How to get help

Collect installation log data

Gather the following log files when none of the above items solves your problem and further investigation is required:

1.       %temp%\netfxsl.log

2.       %temp%\netfxupdate.log

3.       %temp%\MSI*.LOG

To get to the %temp% directory click Start, click Run, type “%temp%” and click OK.

The MSI*.LOG file(s) may not be created by default.  If an MSI*.LOG file does not exist please enable Windows Installer verbose logging and then re-run the installation so that an MSI*.LOG file is created.

The following steps can be used to enable Windows Installer verbose logging:

1.       Use the registry editor (regedit.exe) to navigate the registry hive HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer.

2.       Right-click in the right window pane, select New

3.       click DWORD Value

4.       Type “Debug” and hit enter

5.       Right-click the new registry value Debug and select Modify

6.       Set the Value Data field to “7”.

7.       Next, Right-click in the right window pane, select New

8.       click String Value

9.       Type “Logging” and hit enter

10.   Right-click the new registry value Logging and select Modify

11.   Set the Value Data field to “voicewarmup!”.

Note: After gathering MSI*.LOG, it is recommended that you disable verbose logging by deleting the Debug and Logging values under HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer in your registry.  If these values are left behind, they will cause Windows Installer to create a verbose log for every MSI-based setup that is run on your computer, which can significantly impact the speed of installation.

<update date="10/9/2008"> Fixed a broken link to the Windows Update download troubleshooting knowledge base article. </update>

Hey all,

I posted an article yesterday about .NET Framework setup packaging, and I got some really good follow-up questions that I want to address.  Instead of just posting answers in the comments section of my other article I decided to create a new post to give these issues a little more visibility.  So, here they are in question and answer format.  Thank you all for reading my blog and sending your questions and comments.  If you have any more questions and/or feedback please keep sending them my way….

1.       Could you please clarify about the language versions of SP1 for the .NET Framework 1.1?  There are separate versions of SP1 - one for Windows Server 2003 and another one for other Windows versions. The Windows Server 2003 version is available in 18 languages, the other version is available in 22 languages. Do these SP languages only apply to the setup UI or also to the framework bits (language DLLs)?

There are a couple of really good points here that I forgot to address in yesterday’s post.

The first point is how the version of the .NET Framework 1.1 that is included as part of the Windows Server 2003 OS compares and contrasts to the redistributable version installed by dotnetfx.exe.  Key points here are the following:

·         The .NET Framework 1.1 is installed by the OS optional component manager technology (OCM) using an INF file and sysocmgr.exe when installing or upgrading to Windows Server 2003.

·         The English language version of Windows Server 2003 contains the equivalent of the bits installed by the v1.1 dotnetfx.exe.

·         The non-English versions of Windows Server 2003 contain the equivalent of the bits installed by the v1.1 dotnetfx.exe and the bits installed by the matching language of the v1.1 langpack.exe.

·         If you try to install the v1.1 dotnetfx.exe on Windows Server 2003, it will block you from doing so with a message saying that it is already part of the OS.

·         If you try to install the matching language of the v1.1 langpack.exe on a non-English Windows Server 2003, it will block you from doing so with a message saying that it is already part of the OS.

·         If you try to install a non-matching language of the v1.1 langpack.exe on Windows Server 2003 it will install like on any other OS.

The second point is how the .NET Framework 1.1 service packs are packaged and delivered.  Because the version delivered by dotnetfx.exe is MSI-based and the version delivered by Windows Server 2003 is OCM-based, there are 2 separate service packs – one targeting each installation technology.  If you use Windows Update to install .NET Framework 1.1 SP1, you should only be offered one of the packages though, because Windows Update will examine the OS you are running on and offer you only the package that applies to it.

Also, the .NET Framework 1.1 shipped in 22 languages, but Windows Server 2003 only shipped in 18 languages.  That is why you see a discrepancy in the number of languages offered for each service pack.  The bits that are patched by the two different sets of 1.1 service packs is identical.

2.       The .NET Framework 1.1 language packs also seem to install a localized version of .NET Framework Configuration and Wizards shortcuts under Administrative Tools. This is a pain because I want multilingual satellite assemblies on my server, but I don't want additional multilingual shortcuts.

When we created the .NET Framework 1.1 core and language pack setup and packaging model, we left the installation story for these configuration and wizard shortcuts in a pretty broken state.  In 1.1 setup, dotnetfx.exe will install 2 shortcuts to the Administrative Tools folder with English text and tooltips.  Then each subsequent language pack that is installed on the machine will install 2 additional shortcuts to the Administrative Tools folder.  These additional shortcuts point to the same 2 tools but the text and tooltips are translated into the non-English language.

This scenario does not affect Windows Server 2003 because the .NET Framework 1.1 is installed with the OCM setup technology, and OCM has special logic that enables the installation of multi-lingual shortcuts using an INF file.  This means that on Windows Server 2003, if you install one or more OS MUI language packs, then change your UI language settings, the name and tooltip of the 2 .NET Framework 1.1 shortcuts in the Administrative Tools folder will be automatically translated into your chosen UI language.

The good news is that in v2.0 the .NET Framework redist will no longer install these shortcuts, so this scenario where redundant translated shortcuts are installed will be eliminated.

3.       Will the order of install of the .NET Framework language packs have any significant impact? For example: If I install the English language pack first and then the French will that cause any different behavior than installing them the other way around?

Installing the .NET Framework 1.1 or 2.0 language packs can be done in any order and the machine state will be the same at the end.  There is one thing to note here however – there is not an English language pack.  Instead, the English language resources are installed as part of the dotnetfx.exe core package.

The .NET Framework setup and packaging changed somewhat between v1.0 and v1.1 and there are further changes coming for v2.0 with respect to packaging of core bits and satellite language resources.  I wanted to take a minute and provide an outline of the changes that have gone on as well as some of the reasoning behind them:

.NET Framework 1.0

1.       There is a separate dotnetfx.exe package for each language version of the .NET Framework.  Each package contains an MSI with a unique product code.

2.       The English version contains the bits that provide the core product functionality as well as English language resources that are compiled into the core bits.

3.       The non-English versions contained the core product bits (with English language resources) as well as a set of satellite resource DLLs that provide the appropriate non-English string resources.

4.       Each language version of the .NET Framework SDK contained the equivalent of the matching language version of the .NET Framework redist package as part of the MSI.

5.       Because of items 1 and 4, any time a Windows Installer patch is created for any of the bits that provide the core .NET Framework product functionality, separate logic has to be created to allow the patch to apply to all language versions of the .NET Framework redist and all language versions of the .NET Framework SDK

.NET Framework 1.1

1.       There is a separate dotnetfx.exe package for each language version of the .NET Framework.  Each package contains an MSI with the same product code and installs identical bits.  The only difference between the dotnetfx.exe packages are the setup UI screens – they are translated into the appropriate language.

2.       The dotnetfx.exe packages all contain the bits that provide the core product functionality as well as English language resources that are compiled into the core bits.

3.       There is a separate langpack.exe for each non-English language version of the .NET Framework.  These packages each install a set of satellite resource DLLs that provide the appropriate non-English string resources.

4.       The .NET Framework SDK does not contain the .NET Framework redist.  The SDK setup detects whether or not the .NET Framework redist is already installed on the machine, and if it is not found it blocks the user from installing the SDK until the redist is installed

.NET Framework 2.0

1.       There is a single dotnetfx.exe package.  It contains a single MSI that is marked as language-neutral and setup UI resource DLLs for all supported languages.  It detects the user’s UI language settings and uses that to determine which language to display setup UI in.

2.       The dotnetfx.exe package contains the bits that provide the core product functionality as well as English language resources that are compiled into the core bits.

3.       There is a separate langpack.exe for each non-English language version of the .NET Framework.  These packages each install a set of satellite resource DLLs that provide the appropriate non-English string resources.

4.       The .NET Framework SDK does not contain the .NET Framework redist.  The SDK setup detects whether or not the .NET Framework redist is already installed on the machine, and if it is not found it blocks the user from installing the SDK until the redist is installed

So as you can see from above, there has been a gradual evolution from separate language-specific versions of the .NET Framework to a single language-neutral core package and satellite language packs.  The solution being delivered for .NET Framework 2.0 is what we had originally hoped to ship for .NET Framework 1.1 but the changes required to make the core setup package truly language neutral was too great to finish with high quality in the relatively short time in between shipping 1.0 and 1.1.  We have noted some confusion about why there are multiple dotnetfx.exe packages available on the Microsoft download center for v1.1, and I often hear questions about how the bits each of them installs differ from one another.  I feel like the solution for v2.0 is much cleaner and easier to understand.

Some advantages of this packaging solution are:

1.       Setup developers only need to include one version of dotnetfx.exe for any scenario where their application requires the .NET Framework.

2.       A single patch can be created for any fixes made to core .NET Framework binaries.  This makes the testing matrix within Microsoft simpler and improves the turnaround time for delivering fixes.

Some disadvantages of this packaging solution are:

1.       Setup developers need to include one or more langpack.exe files to create a multi-lingual managed application.

2.       Installing the .NET Framework SDK requires a separate step to install the .NET Framework redist.

I would like to hear any feedback that anyone has about the packaging changes that have happened for the .NET Framework.  Is it making things easier for setup developers?  Or harder (or more confusing)?  Do you have any suggestions for future versions?  If you have any questions or comments about any of the above please post them on my blog or send me a direct email at aaronste (at) microsoft (dot) com.

Hey all, a document I wrote with some tips and tricks for using DUA to update devices that are protected by EWF was published on the MSDN site last night.  You can go to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnembedded/html/embedded11082004.asp to take a look.  Hopefully this will help in some of your scenarios as you try to patch devices in the field.  Please take a look and let me know if you have any feedback, questions, or hit any problems while trying to get this to work.

Hey all, first off I want to apologize for not posting anything in a couple of weeks.  I have had a couple of mini-vacations and been wrapped up with some other stuff, but I'm back now!  I've been working with some Product Support folks I know to turn some documents I wrote for internal troubleshooting into knowledge base articles, and I decided that I wanted to go ahead and post some of the information here so it would be available sooner rather than later.  The first installment is some detailed information about the dreaded 1935 (or 2908) error that sometimes happens when trying to install the .NET Framework or other MSI-based products that install managed assemblies to the GAC.  This is a long post, but hopefully with some useful info.  Let me know if you see any scenarios not covered by this information or have any questions....

1935 Errors in Setup

Abstract

The following document describes causes of 1935 errors during .NET Framework, J# redistributable package, language pack, or Visual Studio setup.  It also explains how to diagnose the root cause of a 1935 error and workaround or fix the error.

Introduction

A 1935 error is one of the most common problems that can prevent a user from being able to install the .NET Framework, J# redistributable package, Visual Studio or any other application that uses the Windows Installer MSIAssembly and MSIAssemblyName tables to install assemblies.

In general, this error means that Windows Installer encountered an error while trying to install assemblies to the Global Assembly Cache (GAC) or the Win32 GAC (WinSxS).  This error is considered fatal and causes setup to fail and initiate rollback.

If the setup is run in UI mode, the user will see a message box indicating that a 1935 error occurred, and it will list the HRESULT and the Windows Installer component GUID of the assembly that caused the error.  If the setup is run in silent mode, the user will see no visible error.  In both cases, more detailed information about the error can be found in the Windows Installer verbose log file.

Affected Products

·         .NET Framework 1.0

·         .NET Framework 1.1

·         .NET Framework 1.1 language packs

·         Visual J# .NET redistributable 1.1

·         Visual J# .NET redistributable 1.1 language packs

·         Visual Studio .NET 2002 (all versions)

·         Visual Studio .NET 2003 (all versions)

Finding log information for 1935 errors that occur during setup

Where to find the log files

In order to diagnose the cause of a 1935 error, it is first necessary to locate information in the Windows Installer verbose log.  If the error occurred during Visual Studio setup or during the .NET Framework or J# redistributable setups that are run as a part of Visual Studio Prerequisites (or Windows Component Update) setup, verbose logging is enabled by default.  The log files vsmsilog*.txt, netfx.log, or jsredistmsi.log in %temp% will provide the necessary information, depending on which product’s setup failed.

If the error occurs during standalone setup for the .NET Framework, .NET Framework SDK or J# redistributable package setup, it will be necessary to rerun the failing setup with an extra command line parameter to enable Windows Installer verbose logging in order to produce a log file with the necessary information to debug the failure.  To enable verbose logging, rerun the setup with the following command line syntax:

Note: The log file location can be controlled by passing a full path after the /l switch to install.exe or inst.exe.  The locations listed in the table are the default locations if no path is provided.

Where to find error information in the log file

To pinpoint the cause of a 1935 error, search for the string return value 3 in a verbose Windows Installer log file.  This will show the exact point in which setup failed and initiated a rollback.  The following is an example of the information written to a Windows Installer verbose log file in the case of a 1935 error:

Error 1935.An error occured during the installation of assembly component {7D4B5591-4C80-42BB-B0E5-F2C0CEE02C1A}. HRESULT: -2146234301. assembly interface: IAssemblyCacheItem, function: Commit, assembly name: Microsoft.Vsa.Vb.CodeDOMProcessor,Version="7.0.5000.0", PublicKeyToken="b03f5f7f11d50a3a", Culture="neutral",FileVersion="7.10.3052.4", ProcessorArchitecture="neutral"

In this example, the assembly named Microsoft.Vsa.Vb.CodeDOMProcessor.dll failed to install properly due to an error with HRESULT value -2146234301.

List of causes of 1935 errors and their HRESULT values

There are many different underlying causes of a 1935 error, each represented by a different HRESULT.  Once you locate the information in the Windows Installer verbose log file indicating which assembly is causing the error and what the HRESULT of the error is, you can use the table below to determine more specific information about the cause:

NOTE: The Windows Installer team created separate error codes for 3 of the above return types starting with the version that shipped with Windows Server 2003.  The following are the new error codes and the return types they correspond to in Windows Server 2003 and in versions of Windows Installer greater than 2.0 (all other return types from the above table continue to be represented by error code 1935):

Resolving 1935 errors that occur during setup

Most of the above HRESULT values in the table of 1935 errors above indicate some kind of setup authoring problem, and they require that the MSI package or some of the files in the package be patched and repackaged.  All return types that begin with FUSION fit into this category.

1935 errors with HRESULT -2147319761 (function not defined in specified dll)

The most common source of a 1935 error is HRESULT -2147319761 (which means that a function is not defined in specified DLL).  This error is typically caused by a mismatch or incompatibility between the version of mscoree.dll in the Windows system directory and the version needed by the product being installed.  Often this can occur if a user has a previous beta version or technology preview build of the .NET Framework installed on their machine (even if they then uninstall it).

There are several possible ways to workaround this type of 1935 error.  The workarounds depend on the product being installed and the OS that the product is being installed on.  Refer to the sections below for more details for the individual products.

.NET Framework

This workaround applies to all versions of the .NET Framework. 

The following steps will fix most cases of a 1935 error with HRESULT -2147319761 on operating systems that do not contain the .NET Framework as part of the operating system (applies to Windows 98, Windows Me, Windows NT 4, Windows 2000, and Windows XP except as noted below):

1. Rename the file %windir%\system32\mscoree.dll (or %windir%\system\mscoree.dll on Windows 98 and Windows Me).  Also, please take note of what the version of this file is to aid in tracking down why this error is occurring.
2. Delete the folder %windir%\system32\urttemp (or %windir%\system\urttemp on Windows 98 and Windows Me) if it exists.
3. Re-run the .NET Framework setup that failed originally.

Because the .NET Framework ships as part of the OS for Windows XP Tablet PC Edition, Windows XP Media Center Edition and Windows Server 2003, it is dangerous to delete mscoree.dll from the system directory because it can affect OS functionality.  In some cases, it is impossible to delete this file because it is under system file protection.  The following steps will fix most cases of a 1935 error with HRESULT -2147319761 on these OS types:

1. Rename the file %windir%\system32\mscoree.dll.  Also, please take note of what the version of this file is to aid in tracking down why this error is occurring.
2. Extract the file mscoree.dll from netfx.cab in the i386 directory of your original OS installation media or network path.
3. Copy mscoree.dll from netfx.cab to %windir%\system32.
4. Re-run the .NET Framework setup that failed originally.

NOTE: This error should not ever be seen for .NET Framework v1.1 on Windows Server 2003 because .NET Framework v1.1 shipped as part of the operating system, and the Windows Installer package for this version should block if a user attempts to install it on this OS.  This error should also not ever be seen for .NET Framework v1.0 on Windows XP Tablet PC or Media Center editions because .NET Framework v1.0 shipped as part of the OS.

J# Redistributable Package, Language Packs, and Visual Studio

In most cases, a 1935 error with HRESULT -2147319761 during installation of the J# redistributable package, .NET Framework or J# redistributable package languages packs, or Visual Studio will require a repair of the highest version of the .NET Framework currently installed on the machine.

If you have the .NET Framework installed via a Windows Installer MSI package, you can perform the following steps to repair the .NET Framework:

1. Rename the file %windir%\system32\mscoree.dll (or %windir%\system\mscoree.dll on Windows 98 and Windows Me).  Also, please take note of what the version of this file is to aid in tracking down why this error is occurring.
2. Delete the folder %windir%\system32\urttemp (or %windir%\system\urttemp on Windows 98 and Windows ME) if it exists.
3. If you are trying to repair the .NET Framework v1.0, locate the file repair.htm in the folder %windir%\Microsoft.NET\Framework\v1.0.3705 and follow the instructions on that page.
4. If you are trying to repair the .NET Framework v1.1, locate the file repairRedist.htm in the folder %windir%\Microsoft.NET\Framework\v1.1.4322\1033 and follow the instructions on that page.
5. Rerun the setup that failed originally.

If you have the .NET Framework installed as part of the operating system and find that it needs to be repaired, you should first try the following steps:

1. Rename the file %windir%\system32\mscoree.dll.  Also, please take note of what the version of this file is to aid in tracking down why this error is occurring.
2. Extract the file mscoree.dll from netfx.cab in the i386 directory of your original OS installation media or network path.
3. Copy mscoree.dll from netfx.cab to %windir%\system32.
4. Re-run the setup that failed originally.

If these steps fail, you may need to rerun OS setup to trigger a repair of the entire .NET Framework.

What to do if the above troubleshooting steps do not work

In some cases, the 1935 error with HRESULT -2147319761 can be caused by orphaned registry keys from a different version of the .NET Framework, and replacing mscoree.dll or repairing the .NET Framework will not fix the error.  In these cases, try to look in the registry key HKLM\Software\Microsoft\.NETFramework and look for any sub-keys or values containing version numbers of previous builds of the .NET Framework.  If any are present, rename or delete them, then try to rerun the previously failing setup.

In addition if you are trying to install the .NET Framework v1.0, delete the following registry keys and any sub-keys and values, if present:

·         HKLM\Software\Microsoft\NET Framework Setup\Full

·         HKLM\Software\Microsoft\NET Framework Setup\Product

NOTE:  Be very careful when directly modifying the registry in this way, particularly on operating systems where the .NET Framework ships as part of the OS.  It is always recommended to backup your registry prior to making direct modifications to it so that you can roll back to a known state.

If there are no orphaned registry keys or deleting orphaned keys did not fix the problem, it may be necessary to completely uninstall and reinstall the highest version of the .NET Framework on the machine.  This can be done by locating the entry in the Add/Remove Programs control panel applet and choosing to uninstall, then reinstalling from the original source.

If uninstalling and reinstalling also does not work, it may be necessary to perform a manual removal of the highest version of the .NET Framework on the machine.

NOTE: Manual removal is not recommended and can be very dangerous if the .NET Framework shipped as part of the operating system.  In these cases, it is recommended to repair the OS by rerunning OS setup.

Additional Information

·         http://support.microsoft.com/default.aspx?scid=kb;en-us;308096

·         http://support.microsoft.com/default.aspx?scid=kb;en-us;824643

·         http://support.microsoft.com/default.aspx?scid=kb;en-us;830646

·         http://support.microsoft.com/default.aspx?scid=kb;en-us;839547

·         http://support.microsoft.com/default.aspx?scid=kb;en-us;872904  

Hey, I was browsing around and found that Microsoft released the redistributable version of Windows Installer 3.0 a couple of days ago.  Check out http://support.microsoft.com/?kbid=884016 for info about new features and some of the key bug fixes.  Most of the new features are related to patching (patch sequencing, patch uninstall, better patch install performance and management).  I remember the first feature that I noticed when I was trying out prerelease builds though - running msiexec /? will actually display the command line parameters now!!  So I don't have to dig into the help docs each time I forget what the exact parameter name is for something I want to do via command line.

Note that Windows Installer 3.0 ships as part of Windows XP SP2 also, so it has been out in the field for a little while, but the redistributable package brings 3.0 to other platforms as well.  There are a couple of pretty big caveats though - Win9x is not supported (meaning Windows 95, 98, 98 SE, and Me).  Also, you have to have Windows Installer 2.0 already installed before you can install the 3.0 redist package.  That is why you see the published system requirements of Windows 2000 SP3 or higher (since SP3 contains Windows Installer 2.0).

Anyway, I encourage you all to try out 3.0 and let me (and others at Microsoft) know what your experiences are - what is good, what is still broken, what features would you like to see in future versions?