Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

  • Aaron Stebner's WebLog

    What to do if Media Center Extender for Xbox 360 setup crashes


    I have heard from a couple of customers who have tried to download and install the software to enable using Xbox 360 as an Extender for Media Center 2005 with Update Rollup 2, but have encountered a crash dialog from the DvcSetup.exe process at the beginning of setup.  I finally located a computer in our test lab that reproduced this issue and found a possible root cause and workaround in case anyone else runs into this.

    Problem description

    The Xbox 360 PC setup package crashes almost immediately after it is launched.  The error dialog indicates that DvcSetup.exe crashed, and it may ask if you want to debug the problem.


    I was able to use the following steps to clean up the machine in our test lab that exhibited this problem:

    1. Go to Add/Remove Programs and remove the .NET Framework 1.1 (and any .NET Framework 1.1 language packs if you have any installed)
    2. Download the .NET Framework cleanup tool, run it and choose to clean up the .NET Framework 1.1
    3. Reinstall the .NET Framework 1.1 
    4. Reinstall the .NET Framework 1.1 SP1

    Details about the root cause if you are interested

    On the machine I investigated, the .NET Framework 1.1 had been installed, but none of the files were correctly installed in the global assembly cache (GAC).  I found that there were folders created for each assembly (for example - %windir%\assembly\GAC\Accessibility\1.0.5000.0__b03f5f7f11d50a3a), but the folders did not actually contain the assembly.  I also saw the following entries in the verbose MSI log file for the .NET Framework 1.1 on this machine:

    MSI (s) (C8:D8): skipping installation of assembly component: {45B8FB98-2A6C-11D6-A551-0090278A1BB8} since the assembly already exists

    There is a bug in the version of Fusion that shipped with the .NET Framework 1.0 and 1.1 where it would skip installing an assembly to the GAC if the folder already existed, even if the file was not in the folder.  Windows Installer uses Fusion to try to install assemblies into the GAC, and as the log file shows, each of the .NET Framework 1.1 assemblies was skipped because Fusion thought they already existed.

    So far, I have only seen one scenario where empty folders exist in the GAC and cause this type of behavior for .NET Framework 1.1 setup.  If you have an operating system installed and have the .NET Framework 1.1 installed, and then you peform a clean install of your operating system to the same partition and choose not to format the partition, OS setup will create a new Windows directory for you.  When it does so, OS setup copies your Windows directory to a backup location and creates the same set of folders that previously existed in your Windows directory.  However, OS setup will not mirror any of the files because it assumes that you will want the copies of the files that are a part of the OS setup that you are currently installing.

    This type of OS install leaves your computer in a state where the .NET Framework 1.1 assembly folders exist in the GAC, but they are all empty, and then due to the bug in Fusion that I previously installed, reinstalling the .NET Framework 1.1 does not fix the problem.  The workaround I described above will work correctly because the .NET Framework cleanup tool will remove these empty directories, which will allow a reinstall of the .NET Framework 1.1 to correctly install the assemblies to the GAC.


  • Aaron Stebner's WebLog

    How to manually reset folder and file permissions in Windows Explorer


    As I was typing out an earlier blog entry about resolving access denied (0x80070005) errors that can happen while installing the .NET Framework, I was intending to link to a post that listed the steps you can take to reset permissions (ACLs) for folders, files and registry keys.  Then as I searched through my previous blog posts I couldn't actually find a post where I listed those steps, so I figured I should list them as a standalone post.

    Resetting folder/file permissions

    1. Launch an instance of Windows Explorer
    2. Navigate to the parent of the folder that you want to reset permissions for
    3. Right-click on the folder and choose Sharing and Security...
    4. Click on the Security tab
    5. Click the Advanced button
    6. Set the permissions you want - typically you will want to allow Administrators, System, and Creator Owner to have full control
    7. Check the box labeled Replace permission entries on all child objects with entries shown here that apply to child objects
    8. Click OK
    9. Click Yes in the dialog box that appears asking if you are sure
    10. Wait while Windows recursively applies the specified permissions to all sub-folders and files

    Also note that there is a tool named subinacl.exe that can be used to automate the process of resetting folder, file and registry permissions so that you don't have to use the set of steps listed above.


  • Aaron Stebner's WebLog

    TurboTax 2009 can fail to install because it thinks the .NET Framework is not installed, even when it is


    I’ve heard from a few customers over the past few days who have had trouble installing the new 2009 version of TurboTax.  In the cases I’ve heard about so far, the installer for TurboTax reports that the .NET Framework 3.5 SP1 is not correctly installed and instructs the user to re-install it.  Unfortunately, attempts to uninstall and re-install the .NET Framework did not help in some of these cases.

    Behind the scenes, it appears that TurboTax setup is running a verification process that is similar to the .NET Framework setup verification tool.  This verification process checks that files and registry keys that should be installed by the .NET Framework 2.0, 3.0 and 3.5 setup packages are correctly installed on the computer.  It is possible for the .NET Framework to be installed but for some of the files and/or registry values to have been removed by some other program (such as a registry cleaner tool, a disk cleanup tool, or even manual deletion by the user).

    If TurboTax reports a problem with the .NET Framework 3.5, it suggests that you try to uninstall and re-install the .NET Framework 3.5.  However, the exact steps needed to do this depend on what version of Windows you are running, and this has ended up causing confusion for the users I’ve heard from so far because the different steps aren’t very well documented in general.

    For Windows XP and Windows Server 2003

    If you are running a version of Windows before Windows Vista (such as Windows XP or Windows Server 2003), then in most cases, you can use the entry in Add/Remove Programs to repair the .NET Framework 3.5 or 3.5 SP1.  If that doesn’t help, then you can use the steps in this blog post to remove and then re-install the .NET Framework 3.5 SP1.

    For Windows Vista or Windows Server 2008

    If you are running Windows Vista or Windows Server 2008, then the .NET Framework 2.0 and 3.0 are installed as OS components.  As a result, the repair steps are more complicated.  You will need to try the following:

    1. Try to repair the .NET Framework 3.5 or 3.5 SP1 using the entry in the Programs and Features control panel.
    2. If that doesn’t help, try to use the steps in this blog post to remove and re-install the .NET Framework 3.5 SP1.
    3. If the above steps do not help, run sfc.exe /scannow to attempt to repair the files that are a part of your OS (which will also repair some parts of the .NET Framework).

    For Windows 7

    If you are running Windows 7, then the .NET Framework 2.0, 3.0 and 3.5 are all installed as OS components, and you cannot remove or re-install these versions using the Programs and Features control panel.  On Windows 7, this is your only built-in repair option:

    Run sfc.exe /scannow to attempt to repair the files that are a part of your OS (which will also repair some parts of the .NET Framework).

    What to do if the above doesn’t help

    Unfortunately, sfc.exe will only repair files that are protected by Windows Resource Protection.  For the .NET Framework, only binary files that can be repaired using sfc.exe.  Non-binary files (such as .config files) and registry keys cannot be repaired using sfc.exe.  For non-binary files, the only options are to manually replace them with files from other computers or to repair your OS.  For registry keys, the only options are to manually re-create them in regedit.exe or to repair your OS.

    Here are some steps I’ve been able to use to narrow down the exact missing files and/or registry keys that cause TurboTax setup to think that the .NET Framework 3.5 SP1 is not correctly installed:

    1. Download and run the TurboTax verification utility from http://turbotax.intuit.com/support/kb/installing/errors/7659.html
    2. When the utility finishes, click the button named Save Logs on Desktop
    3. Go to your desktop and open the zip file named TurboTax2009UtilityLogFiles*.zip
    4. Find the file named *_TurboTax 2009 Utility – *.log (where the first * is a date-time stamp and the 2nd * is a version number)
    5. Search for the string ****ERROR**** in this log file and take note of the files and/or registry keys that it reports are missing

    From the information in this log file, it is usually possible to figure out what files and/or registry keys need to be manually repaired on the computer.  So far, the cases I’ve seen reported missing .config files and we have been able to get TurboTax setup to run correctly after copying the .config files from another computer or downloading them from here and putting them in the locations reported in this log file.

    If you run into problems getting TurboTax 2009 setup to run correctly due to errors related to the .NET Framework 3.5, I encourage you to try the steps above.  If they don’t help, please don’t hesitate to leave a comment on my blog and/or contact me and I’ll try to help as best as I can.

    <update date="2/3/2010"> Added a link to a zip file that I posted with the .config files that have been causing the majority of the issues with TurboTax setup that I've seen so far. </update>


  • Aaron Stebner's WebLog

    How to repair the .NET Framework 1.1 that ships as part of the OS on Windows Server 2003


    The .NET Framework 1.1 ships as an OS component on the 32-bit Windows Server 2003 family of operating systems.  This .NET Framework component is a hidden, always-installed component with the exception of ASP.NET (which can be found as a selectable item underneath the Application Server item in the Add/Remove Windows Components control panel applet).

    I have seen cases where the .NET Framework 1.1 stops working correctly on Windows Server 2003 (often due to bugs in daily builds of the .NET Framework 2.0).  In those cases, it is useful to perform a repair to get the .NET Framework 1.1 back to a known good state.  However, it can be difficult to figure out how to repair .NET 1.1 in these scenarios because the component is hidden and because there is some specific logic in the setup DLL that installs this component that prevents uninstall and reinstall after OS setup has completed.

    In general, you can repair the .NET Framework 1.1 that ships with Windows Server 2003 by re-running OS setup and choosing to repair/reinstall, which will trigger the .NET Framework 1.1 component setup to rerun.

    In addition, the following steps can be performed in order to repair the .NET Framework 1.1 on Windows Server 2003 while also avoiding the need to run a full OS reinstall:

    1. Delete the registry value netfx under HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\OC Manager\Subcomponents
    2. Create a file named netfx_repair.inf that contains the following text (or download it from here):

      Signature = "$Windows NT$"

    3. Open a cmd prompt and run the following command: sysocmgr /i:<full path to netfx_repair.inf>.

      This will bring up the Windows optional component installer wizard.  Press next and installation/repair of the .NET Framework 1.1 component will begin.  You will be asked for a path to install the files from if the location listed in the SourcePath value under HKLM\Software\Microsoft\Windows\CurrentVersion\Setup is not accessible or no longer contains the necessary OS source files.  If this happens, you will need to point the wizard to the i386 directory of the OS source disk or a network share that contains the files.  Keep in mind that if you have a version of Windows Server 2003 with a service pack integrated into it, you will need to use a source location that also includes the service pack.

    4. After the wizard completes installation, you will have to manually rerun a modified command line to install assemblies to the GAC because the command line used by the .NET Framework 1.1 component only works correctly when OS installation is in progress.  The command line is the following:

      "%windir%\Microsoft.NET\Framework\v1.1.4322\gacutil.exe" /f /il %windir%\Microsoft.NET\Framework\v1.1.4322\assemblylist.txt

      You should substitute %windir% with the actual Windows directory on your system.

    <update date="11/1/2005"> There is a Knowledge Base article that also describes how to troubleshoot .NET Framework 1.1 installation issues on Windows Server 2003 that can be useful in this type of scenarios.  You can find it at this location. </update>

    <update date="9/29/2008"> Added a note about using source files with integrated service packs if the OS was originally installed with a service pack integrated. </update>


  • Aaron Stebner's WebLog

    How to detect what .NET Framework 1.1 service pack is installed


    I have seen a few questions on the newsgroups about how to determine whether or not the .NET Framework 1.1 SP1 is installed on your machine.  A colleague pointed me to a KB article that describes a method of looking at file versions to determine this.  We created a new registry hive that started getting installed in the .NET Framework 1.1 specifically to address this and a few other types of detection issues and make this simpler for 3rd party developers, so I wanted to quickly outline how to check for this in the .NET Framework 1.1 and new versions moving forward (it will take a bit for my request to have that KB article updated to go into effect on the live KB site).

    Basically you need to query for the existence of a registry value and then check the data in that value.  Here is where it is located:

    • Key Name: HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v1.1.4322
    • Value: SP
    • Data type: REG_DWORD

    The data in this SP value tells you which service pack is installed for the .NET Framework 1.1.  For future versions of the .NET Framework, you will just need to change the part of the key named v1.1.4322 to be the version you are interested in.

    Note that this method cannot be used to tell you whether or not you have any QFE's or GDR's installed for the .NET Framework.  If anyone out there needs to be able to detect on this granular of a level, let me know via a comment or email and I can dig into this further.

    There are also other alternative ways of detecting the presence of the .NET Framework 1.0 service packs, I will post something about that when I figure out the exact details of how to do that.

    Hope this helps....


  • Aaron Stebner's WebLog

    What .NET Framework version numbers go with what service pack


    I got a comment from a customer in response to a previous blog post asking about file versions for the various versions and service packs of the .NET Framework.  I was planning on just navigating to an MSDN site and replying with a link, but I couldn't find anything like that in any MSDN article or any KB article, so I figured I could come up with a quick table listing them.  Keep in mind that not every file is updated by every service pack, so you may not see this exact version for all of the files that are part of the .NET Framework.  Also, because of some of the magic that the Visual Studio and .NET Framework build lab uses to build some of the files that are part of the .NET Framework, you may see a .NET Framework-like version number (one that starts with 1.0, 1.1, or 2.0) or a Visual Studio-like version number (one that starts with 7.0, 7.10, or 8.0).

    .NET Framework product version

    Service pack level


    .NET Framework 1.0

    Original release

    1.0.3705.0 and 7.0.9466.0

    .NET Framework 1.0

    Service pack 1


    .NET Framework 1.0

    Service pack 2

    1.0.3705.288 and 7.0.9502.0

    .NET Framework 1.0

    Service pack 3

    1.0.3705.6018 and 7.0.9951.0

    .NET Framework 1.1

    Original release

    1.1.4322.573 and 7.10.3052.4

    .NET Framework 1.1

    Service pack 1

    1.1.4322.2032 (if you have the MSI-based 1.1 SP1 installed) or 1.1.4322.2300 (if you have the OCM-based 1.1 SP1 installed on Windows Server 2003) and 7.10.6001.4

    .NET Framework 2.0

    Beta 1

    2.0.40607.16 and 8.0.40607.16

    .NET Framework 2.0

    Beta 2

    2.0.50215.44 and 8.0.50215.44

    .NET Framework 2.0

    Original release

    2.0.50727.42 and 8.0.50727.42

    .NET Framework 2.0

    Service pack 1

    2.0.50727.1433 and 8.0.50727.1433

    .NET Framework 2.0

    Service pack 2

    2.0.50727.3053 and 8.0.50727.3053

    .NET Framework 3.0

    Original release

    3.0.04506.26 (on Windows Vista) and 3.0.04506.30 (on downlevel operating systems)

    .NET Framework 3.0

    Service pack 1


    .NET Framework 3.0

    Service pack 2


    .NET Framework 3.5

    Original release

    3.5.21022.8 and 9.0.21022.8

    .NET Framework 3.5

    Service pack 1

    3.5.30729.1 and 9.0.30729.1

    .NET Framework 4

    Original release

    4.0.30319.1 and 10.0.30319.1

    Please note that it is definitely not reliable to use the file versions in the above table to detect the installed service pack level.  If you're interested in accurately determining what version of the .NET Framework is installed and what service pack is installed I would recommend checking out the blog post and sample code that I previously posted at this location.

    <update date="1/31/2006"> Added another possible version number for 1.1 SP1.  The files have different versions depending on whether you have the MSI-based .NET Framework 1.1 package installed or the OCM-based .NET Framework 1.1 package that is included as a part of Windows Server 2003 </update>

    <update date="3/3/2006"> Added a column to the table for the final release of the .NET Framework 2.0 now that it has shipped </update>

    <update date="3/20/2007"> Added a column to the table for the final release of the .NET Framework 3.0 now that it has shipped </update>

    <update date="3/6/2008"> Added columns to the table for the .NET Framework 2.0 SP1, the .NET Framework 3.0 SP1 and the .NET Framework 3.5 now that they have shipped </update>

    <update date="8/14/2008"> Added columns to the table for the .NET Framework 2.0 SP2, the .NET Framework 3.0 SP2 and the .NET Framework 3.5 SP1 now that they have shipped </update>

    <update date="4/27/2010"> Added a column to the table for the .NET Framework 4 </update>


  • Aaron Stebner's WebLog

    How to troubleshoot failure to install Document Explorer 2005 during VS 2005 setup


    I have heard from several customers who have run into problems installing Visual Studio 2005 because the component named Microsoft Document Explorer 2005 fails to install and Visual Studio setup quits when that happens.  I wanted to give a bit more information about what this component is and where logging information can be found to attempt to track down why this installation might fail.

    Document Explorer 2005 is a redistributable package that delivers the 8.0 version of dexplore.exe.  This is the help viewer that is used by Visual Studio 2005, and by other products such as the Windows SDK.  In previous versions of Visual Studio, dexplore.exe was installed as a part of the main Visual Studio MSI or as a part of the MSDN MSI, but in VS 2005, it was separated into its own standalone package, and it is installed as a prerequisite before the main Visual Studio MSI.

    The setup for Document Explorer 2005 uses the same external UI handler as the .NET Framework 2.0 redistributable and SDK (described in more detail in this blog post and in this blog post).

    Visual Studio 2005 setup runs the setup package for Document Explorer 2005 in silent mode.  In cases where this package fails during Visual Studio 2005 setup, you can run dexplore.exe directly from the folder <VS install disc>\wcu\DExplore\ in order to see the error message that is being generated.

    This package creates the following log files in the %temp% directory on a system:

    • dd_dexploreui*.txt
    • dd_dexploremsi*.txt

    In both of these cases, the * in the name of the files is a randomly generated ending to ensure that each time you run setup it will create a unique file and not overwrite existing log files.

    If you do not get any useful error information by running the setup package directly, it can be useful to examine the contents of these log files.  In particular, you can search for the string return value 3 in dd_dexploremsi*.txt and that will usually lead you to the error that causes the setup package to fail.

    If you have trouble locating error information, please contact me or leave a comment on this blog post and I will try to help.


  • Aaron Stebner's WebLog

    Fixing a .NET Framework 4.5.1 detection logic problem on Windows 8.1


    Last week, I posted an updated version of the .NET Framework setup verification tool that supports verifying the .NET Framework 4.5.1. This past weekend, a customer reported a problem where the tool wasn’t correctly detecting that the .NET Framework 4.5.1 is installed on Windows 8.1. The .NET Framework 4.5.1 is installed as a part of the OS on Windows 8.1, and it isn’t possible to uninstall it, so there had to be something wrong with the detection logic in the tool.

    After some investigation, I discovered a problem with the detection logic that is documented in the .NET Framework 4.5.1 Deployment Guide for Developers. The deployment guide says that an application can test whether the .NET Framework 4.5 or later is installed by checking the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full folder in the registry for a DWORD value named Release. A value of 378758 means that the .NET Framework 4.5.1 is installed. This logic works correctly for the redistributable version of the .NET Framework 4.5.1. However, on Windows 8.1, the Release value is set to 378675 instead, so this logic doesn’t work on Windows 8.1.

    I have updated all of the following tools and samples to correctly detect the .NET Framework 4.5.1 in both the redistributable case and the Windows 8.1 OS install case:

  • Aaron Stebner's WebLog

    Sample code to detect .NET Framework 1.0 and 1.1 and service packs


    Hey all,

    In response to some suggestions from folks who read my blog posts describing how to detect the presence of .NET Framework 1.0 service packs and .NET Framework 1.1 service packs, I wrote up a quick sample application that shows how to implement the detection methods I recommended.  You can download the sample code here.

    In this sample, I detect the presence of the .NET Framework core packages for 1.0 and 1.1, and then if I find that they are installed, I detect the service pack level also.  The sample simply pops up a message box for each version, but could be easily updated to perform some conditional action (as part of a 3rd party setup or something like that).

    The code is provided as an example only....I hope it will help better explain how to implement a detection strategy for the .NET Framework and its service packs that will continue to work when future service packs are released.  Let me know if you have any problems or questions.....

    <update date="6/4/2010"> Fixed broken link to the sample code. </update>


  • Aaron Stebner's WebLog

    Details about setup for the .NET Framework 2.0 configuration tool


    Ever since I posted this blog entry last month about how the Administrative Tools shortcuts were moved from the .NET Framework 2.0 redistributable to the SDK, I have gotten multiple follow-up questions and comments from customers about this scenario.  In most cases, the folks who contacted me are system administrators who manage servers and want to change .NET Framework security settings but do not want to incur the overhead of installing the entire SDK on their server.

    I was on the .NET Framework setup team when the decision was originally made to move the configuration tool to the SDK and remove the wizard tool altogether.  At the time, the setup team and the feature teams decided that these type of graphical user interfaces were advanced features more appropriate to an SDK than to a redistributable that is intended to be installed on end-user machines.  For example, many end users on XP Home found it strange to see administrative tools related to a product called the .NET Framework that they did not know was even installed on their system (because it was pre-installed by their OEM or via some other application).

    However, after hearing so much feedback I decided to dig into this scenario in a bit more detail, especially considering that I hadn't thought through the scenario where a system administrator would have to install a 300+ megabyte SDK in order to manage security policy settings.

    According to the folks I know on various .NET Framework teams, the official way to administer security settings on a system that only has the .NET Framework 2.0 redistributable installed (and not the .NET Framework 2.0 SDK or Visual Studio 2005) is to use the command-line tool named caspol.exe that ships in %windir%\Microsoft.NET\Framework\v2.0.50727 as part of the .NET Framework 2.0 redistributable.  There is some in-depth information about how to do this in this MSDN document.

    That being said, I decided to look into the .NET Framework 2.0 SDK setup to see exactly how the configuration tool is installed and determine whether or not there is an easy way to extract that information and transplant it onto a machine with only the .NET Framework 2.0 redist installed.  I started by downloading the .NET Framework 2.0 SDK, extracting netfxsdk.msi from the setup.exe package and opening it in Orca.  I found the following information:

    • The configuration tool appears to be comprised of 4 files - mscorcfg.dll, mscorcfg.msc, mscormmc11.cfg and mscormmc.dll
    • The file mscorcfg.dll is installed to the GAC and to the local file system
    • There are several registry entries associated with the component that installed mscormmc.dll
    • There is a shortcut to mscorcfg.msc that gets installed to the Administrative Tools folder on the system

    Armed with this data, I decided to experiment a bit and see if I could build an MSI package that would install the configuration tool on a system that already had the .NET Framework 2.0 installed.  I used the WiX toolset and created an MSI with the information described above.  Then I installed it on a system that had only the .NET Framework 2.0 redistributable and it appeared to work correctly, though I haven't used this tool much in the past to truly know how well it was functioning.

    If you are curious, you can see the WiX source (WXS) file that I created for this experiment to get a better idea of how things are structured, and you can compile it into an MSI yourself by downloading the latest build of the WiX toolset.  Alternatively, you can download a compiled version of this MSI from this location.

    Please note that while it appears to work correctly, this method of installing the .NET Framework 2.0 configuration tool is unsupported.  For example, if any security related issues were to be found in any of these files, they would not be serviceable if installed on a system using a means such as this.

    <update date="12/17/2008"> Updated the WiX source code from WiX v2.0 to WiX v3.0 and added a download link for the compiled MSI. </update>

    <update date="3/11/2009"> Updated download links to point to my new file server. </update>


  • Aaron Stebner's WebLog

    Mailbag: Do I need still need older versions of the .NET Framework on my system after installing .NET Framework 3.5 SP1?



    I recently installed the .NET Framework 3.5 SP1 on my system.  Afterwards, I looked in Add/Remove Programs, and it shows that I have all of the following versions of the .NET Framework installed on my system:

    • Microsoft .NET Framework 1.0
    • Microsoft .NET Framework 1.1
    • Microsoft .NET Framework 2.0 SP2
    • Microsoft .NET Framework 3.0 SP2
    • Microsoft .NET Framework 3.5 SP1

    Do I need any of these older versions of the .NET Framework now that I’ve installed the .NET Framework 3.5 SP1, or can I safely uninstall them?


    When you install the .NET Framework 3.5 SP1, it will also install the .NET Framework 2.0 SP2 and the .NET Framework 3.0 SP2 behind the scenes.  You cannot use the .NET Framework 3.5 SP1 unless you also have the .NET Framework 2.0 SP2 and 3.0 SP2 installed.  Therefore, you will not be allowed to uninstall the .NET Framework 2.0 SP2 or 3.0 SP2 if you have the .NET Framework 3.5 SP1 installed.  If you try to uninstall those versions of the .NET Framework, their uninstall processes will block and tell you that they are needed by another application on your system.

    The .NET Framework 1.0 and .NET Framework 1.1 can be installed side-by-side with the .NET Framework 2.0, 3.0 and 3.5.  Most applications that were created for the .NET Framework 1.0 or 1.1 will automatically use the .NET Framework 2.0 instead if it is installed on the system.  In most cases, that means you do not need to keep the .NET Framework 1.0 or 1.1 installed on your system if you already have the .NET Framework 2.0 installed.

    However, there are some applications that are configured to require a specific version of the .NET Framework, even if later versions of the .NET Framework are installed.  If you have any applications like that on your system and try to run them without installing the .NET Framework 1.0 or 1.1, you will get an error message that looks like the following:

    MyApplication.exe - .NET Framework Initialization Error
    To run this application, you first must install one of the following versions of the .NET Framework:
    Contact your application publisher for instructions about obtaining the appropriate version of the .NET Framework.

    In the above error message, the version number will be v1.0.3705 if you need to install the .NET Framework 1.0, and it will be v1.1.4322 if you need to install the .NET Framework 1.1.

    If you end up seeing any error messages like this, you can re-install the .NET Framework 1.0 or 1.1 in order to resolve the errors.  If you don't end up seeing any error messages like this, then you don't need to worry about re-installing the .NET Framework 1.0 or 1.1.

  • Aaron Stebner's WebLog

    How to manually install the various pieces of Update Rollup 2 for Media Center 2005


    I have previously written about a couple of instances where Update Rollup 2 for Windows XP Media Center Edition 2005 setup can fail because other Windows hotfixes have been installed in such a way that they interfere with the hotfixes that Update Rollup 2 tries to install.  Those cases and steps to workaround them are described here and here.

    A few customers who have run into one of these issues have been unable to use the recommended workarounds because the conflicting hotfix fails to uninstall correctly.  This can happen due to uninstall bugs in the other hotfixes or in cases where the other hotfixes were installed with a command line switch that intentionally prevents it from being uninstalled.

    If you are unable to install Update Rollup 2 due to a conflicting hotfix that cannot be uninstalled, you can use the following steps to extract the individual pieces of Update Rollup 2 setup and install them individually to workaround this problem. 

    NOTE: These steps should only be used as a last resort, so please make sure to try the other workarounds that I have documented before trying these steps.

    1. Download the setup package for Update Rollup 2 and save it to your local hard drive
    2. Click on the Start menu, choose Run and type cmd
    3. Change directories to the folder that you saved the Update Rollup 2 setup package to in step 1 by typing cd /d <directory> (you will need to replace <directory> in this command with the actual path that you saved the Update Rollup 2 setup package to in step 1, for example - cd /d c:\downloads)
    4. Run WindowsXPMediaCenter2005-KB900325-usa.exe /x:c:\temp to extract the contents to a temporary folder
    5. Type cd /d c:\temp\bin to change to the directory you extracted the Update Rollup 2 setup package to in step 4 above
    6. Run WindowsMedia10-KB895572-x86.exe /norestart (this may fail due to this issue; if it does, ignore the failure and continue on to the next package)
    7. Run WindowsXP-KB891593-x86.exe /norestart (this may fail due to this issue; if it does, ignore the failure and continue on to the next package)
    8. Run WindowsXP-KB895961-x86.exe /norestart
    9. Run WindowsXP-KB899337-v2-x86.exe /norestart (this may fail due to this issue; if it does, ignore the failure and continue on to the next package)
    10. Run WindowsXP-KB899510-x86.exe /norestart
    11. Run WindowsXP-KB888795-x86.exe /norestart
    12. Run WindowsXP-KB902841-x86.exe /norestart
    13. Run KB900325.exe /norestart
    14. Run wmfdist95.exe /Q:A /R:N /c:"wmsetsdk.exe /WMFDIST /Q /R:N /DisallowSystemRestore"
    15. Reboot your system


  • Aaron Stebner's WebLog

    Assembly installation error codes in .NET Framework 2.0 setup


    I have written several posts in the past about 1935 errors that can happen during the installation of the .NET Framework and other applications that install managed code to the GAC (most notably, this troubleshooting guide).

    Starting in version 2.0, you will no longer see 1935 errors during .NET Framework redistributable setup.  This is because we created a new custom action to install assemblies to the GAC instead of using the built-in MsiAssembly and MsiAssemblyName tables.  This custom action was created to eliminate the need to carry 2 copies of each assembly in the setup package for the .NET Framework in order to install to both the GAC and the local file system.  More information about why we would otherwise need to carry 2 copies of each assembly can be found in this previous blog post.

    The custom action that installs assemblies to the GAC during .NET Framework setup calls fusion APIs directly and uses information in the custom MSI tables named Assembly and AssemblyName (instead of MsiAssembly and MsiAssemblyName) to determine what assemblies to install to the GAC.  The custom action also logs a new set of error codes in case of any failures.

    The following is a list of all possible assembly installation errors that can occur during .NET Framework 2.0 setup:

    • 25000 = "Unexpected error occurred during assembly configuration. This setup package may be bad."
    • 25001 = "Unexpected error occurred during assembly configuration. Function '[2]()' returned [3]."
    • 25002 = "Error occurred while initializing fusion. Unable to load [2]. System error: [3]"
    • 25003 = "Error occurred while initializing fusion."
    • 25004 = "Failed to execute query '[2]'. Is table AssemblyName missing in the MSI package?"
    • 25005 = "There's no matching record for component '[2]' in AssemblyName table."
    • 25006 = "Error occurred while initializing fusion. Setup could not find function 'LoadLibraryShim' in mscoree.dll. System error: [2]"
    • 25007 = "Error occurred while initializing fusion. Setup could not load fusion with LoadLibraryShim(). Error: [2]"
    • 25008 = "Unexpected error occurred during assembly installation."
    • 25010 = "Failed to install assembly '[2]' because the check of the module's hash failed." (the equivalent of fusion error code

      0x80131039 - COR_E_MODULE_HASH_CHECK_FAILED)
      25011 = "Failed to install assembly '[2]' because one or more modules specified in the manifest cannot be found." (the equivalent of fusion error code 0x80131042 - FUSION_E_ASM_MODULE_MISSING)

    • 25012 = "Failed to install assembly '[2]' because one or more modules were streamed in which did not match those specified by the manifest. Invalid file hash in the manifest?" (the equivalent of fusion error code 0x80131043 - FUSION_E_UNEXPECTED_MODULE_FOUND)
    • 25013 = "Failed to install assembly '[2]' because strong name signature could not be verified. Was the assembly built delay-signed?" (the equivalent of fusion error code 0x80131045 - FUSION_E_SIGNATURE_CHECK_FAILED)
    • 25014 = "Failed to install assembly '[2]' because of invalid file or assembly name. The name of the file must be the name of the assembly plus .dll or .exe." (the equivalent of fusion error code 0x80131047 - FUSION_E_INVALID_NAME during install)
    • 25015 = "Failed to install assembly '[2]' because of system error: [3]" (this is a catch-all for all error codes not listed above during installation)
    • 25020 = "Failed to uninstall assembly '[2]' because the strong name is not valid." (the equivalent of fusion error code 0x80131047 - FUSION_E_INVALID_NAME during uninstall)
    • 25021 = "Uninstall of assembly '[2]' is not allowed." (the equivalent of fusion error code 0x80131049 - FUSION_E_UNINSTALL_DISALLOWED)
    • 25022 = "Failed to uninstall assembly '[2]' because of system error: [3]" (this is a catch-all for all error codes not listed above during uninstallation)


  • Aaron Stebner's WebLog

    What to do if I get package load failures in the final release of VS 2005?


    IMPORTANT UPDATE - I have posted an updated set of steps for working around package load failures.  Please read that blog post instead of this post because it contains additional information not listed here.  I do not want to take this post down because I want to keep the comments so others can read them, but this post is essentially obsolete due to the new blog entry I have posted.

    Since the final release of Visual Studio 2005 and the .NET Framework 2.0, I have heard from several customers who have been using beta versions of VS, SQL and .NET 2.0, and have followed the uninstall steps to the best of their ability (including trying the auto-uninstall tool linked at the top of the uninstall instructions page) but are still encountering Package Load Failure error messages in the VS IDE after installing the final release.

    If you currently have the final release of any version of VS 2005 installed (including the Express Editions), and you are encountering package load failures, here is what I recommend that you do to resolve these issues:

    1.  Try to run the VS 2005 troubleshooting tool

    Before trying the next set of steps, please download and run the VS 2005 troubleshooting tool.  This tool is built on the same code base as the auto-uninstall tool, but it has knowledge of some specific problems that existed in previous beta versions of VS 2005 and knows how to go in and surgically clean them up.

    2.  Try to run the following command line to clear out the native image cache

    Click on the Start menu, choose Run and type cmd, then type rd /s /q %windir%\assembly\NativeImages_v2.0.50727_32\Microsoft.VisualStu# and press enter to remove native images from the cache.

    3.  Manually search for orphaned files in the GAC

    I have found that there are some cases where some additional files are getting orphaned on the machine that my test scenarios haven't caught yet (because we shipped a lot of different beta versions and I don't have the time to test out every uninstall permutation, etc).  If I haven't seen the issue in my testing, it hasn't been added to the troubleshooting tool and therefore that tool won't always be helpful.

    In general, the orphaned files that cause package load failures are located in the GAC (which is located at %windir%\assembly on your machine).  So, if you have already run the troubleshooting tool and are still running into package load failures, here are some additional steps that have proven useful in identifying additional orphaned files:

    1. Download the FSnap tool and extract it to c:\fsnap.exe on your machine
    2. Run c:\fsnap.exe /bs c:\windows\assembly\ > c:\file_list.txt
    3. Look at the contents of c:\file_list.txt for any files with version number 2.0.xxxxx.xx or 8.0.xxxxx.xx where the xxxxx.xx is not equal to 50727.42
    4. Remove the files that fit this criteria using gacutil.exe (which is installed to %ProgramFiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin if you have VS 2005 installed and chose to install the .NET Framework SDK tools, or can be installed by installing the .NET Framework 2.0 SDK) or by using DOS commands in a cmd prompt

    I have found it useful to import the contents of c:\file_list.txt into Excel and then sort alphabetically by column G (which is the file version column).  That makes it easier to zero in on files that have suspicious version information.

    Please note that you will need to change the paths in the steps above if you have your OS installed on a drive other than C.  Also, make sure that you include the trailing \ after the "assembly" folder name or else the FSnap tool will not work correctly. 

    4.  Help me make the troubleshooting tool better

    If you use FSnap and manually delete files and that resolves the package load failures you are seeing, I would appreciate it if you could let me know which files you removed that fixed the issue (either via the contact form or a comment on this post).  If I see common problems that the tool is not yet able to fix, I can add them to the tool and post an updated version to help everyone else out who might hit the same issue.

    Hopefully this will help resolve any lingering package load failure issues that you might be seeing.  If these steps still do not work please contact me and let me know.

    <update date="11/18/2005"> Added an additional step to clear out the native image cache based on findings I posted here </update>

    <update date="12/16/2005"> Added an updated link to a newer set of steps at the top of this blog post </update>


  • Aaron Stebner's WebLog

    Tool to automatically collect and cab VS 2008 and .NET Framework 3.5 setup log files


    I wrote a post yesterday with a list of the names and locations of all of the log files produced during Visual Studio 2008 and .NET Framework 3.5 setup.  As you can see in that post, the list of possible log files is very long, and that makes it annoying when attempting to gather the logs and send them back to Microsoft so that we can help troubleshoot installation issues.

    Fortunately, Sandhya, a colleague of mine, has written a tool that will automatically gather all of the VS 2008 and .NET Framework 3.5 setup log files it can find from your system and create a cab file containing them so you have a single compressed package that can be sent to Microsoft for troubleshooting purposes.

    How to use the Collect tool

    The tool can be downloaded from http://go.microsoft.com/?LinkId=8967043.  It is a Win32 console application, so you can extract it from the zip file and double-click on it to run it.  It will create a file named %temp%\vslogs.cab on your system after it has gathered all of the log files.

    Note - after the tool finishes running, you can get to your %temp% folder to find the file vslogs.cab by clicking on the Start menu, choosing Run, typing %temp% and clicking OK.

    What to do if the Collect tool does not work correctly on your system

    If the tool encounters any problems, you can do the following to re-run it from a cmd prompt and see more detailed error information:

    1. Click on the Start menu, choose Run, type cmd and click OK
    2. Run collect.exe from the cmd prompt that appears
    3. When doing this, you will see information displayed in the cmd prompt with more details about which actions it is performing, what log files it found, etc

    <update date="5/23/2008"> Updated link to log collection tool to point to the new location </update>


  • Aaron Stebner's WebLog

    Notes about a couple of possible issues while using the SubInAcl tool



    Important note - if you were referred to this blog post from this knowledge base article and are having trouble running SubInAcl or reset.cmd, please try the steps listed in my other blog post first - http://blogs.msdn.com/b/astebner/archive/2006/09/04/solving-setup-errors-by-using-the-subinacl-tool-to-repair-file-and-registry-permissions.aspx.


    A while back, I posted some instructions for using a tool from the Windows Resource Kit named SubInAcl that can be used to update file, folder and registry permissions.  This tool can help fix some types of access denied errors that can be encountered while trying to install products, hotfixes and service packs on Windows.

    Since that original post, I have heard from some people who have run into various types of problems while attempting to install and use the SubInAcl tool.  I wanted to post more details about a few of these scenarios in case other folks run into similar issues in the future.

    Issue 1 - Running SubInAcl reports an error on some non-English operating systems

    On some non-English operating systems, customers have reported seeing errors like the following when trying to use the command lines listed in my previous blog post:

    LookupAccountName : HKEY_CURRENT_USER:administrators 1337 The security ID structure is invalid.

    The reason for this error is that on some non-English operating systems, the name of the Administrators group is translated into the OS language.  If you are running SubInAcl on a non-English OS where the name of the Administrators group is translated, you will need to update each of the command lines for SubInAcl to specify the translated name of the Administrators group.

    Issue 2 - SubInAcl.msi fails to install

    I have heard from a few people who were not able to get the SubInAcl.msi installer to work correctly on their systems, which prevented them from being able to use the tool.  If you run into an error while installing SubInAcl.msi to install this tool, you can get a copy of the tool that does not require a full installation from an alternate location by using the following steps:

    1. Download SubInAcl.zip and save it to your local computer
    2. Extract the contents of the zip file to a local folder on your system
    3. Use the steps in the previous blog post to run SubInAcl from the extracted location with the following modifications:
      1. Skip step 1 - there is no need to download and install subinacl.msi because subinacl.zip contains the same files that would normally be installed by subinacl.msi
      2. Depending on where you extract the zip file to in step 2 above, you may need to edit reset.cmd and change the folder path that it is trying to run subinacl.exe from

    Note - you should first attempt to install and run SubInAcl.msi before downloading and extracting this zip file.  This zip file is only intended for cases where for some reason, SubInAcl.msi will not install correctly - which unfortunately can sometimes happen because of one of the same issues that SubInAcl is designed to fix.

    Issue 3 - How to get SubInAcl to create a log file

    SubInAcl is a console application, which means that the output that it prints will be displayed in the console window by default.  For the command lines listed in my previous blog post, SubInAcl prints a lot of information, and if any errors occur, it will quickly scroll off the screen and you won't be able to see the details of the errors.

    For a console application like SubInAcl, running it from a cmd prompt and putting a greater than sign and then the name of a file at the end of the command line (such as > %temp%\subinacl_output.txt) will cause the output to be redirected to a file.  I recently updated the command lines in that post and in the example script I posted on my file server to use this syntax to redirect the output to a file instead of printing it to the console.

    Note - creating a log file as described above will not work if you run SubInAcl from the Windows start menu.  It has to be run from a cmd prompt in order to allow the log file to be created.

    <update date="3/30/2009"> Fixed broken download links that are contained in this post. </update>

    <update date="10/7/2014"> Added a note to the top of this post with alternate instructions for people who were referred to this blog post from this knowledge base article. </update>

    <update date="4/14/2015"> Clarified the steps in Issue 2 </update>



  • Aaron Stebner's WebLog

    VS 2005 setup fails with 1935 or 2908 error

    I have heard from a couple of customers who have tried to install the final release of Visual Studio 2005 or one of the Express Editions and have gotten 1935 (or 2908) errors with HRESULT values of 0x8002802F, and then setup failed and rolled back.  The cases I have seen so far have had the same root cause as the problem I described in this previous blog post.

    In the cases I have seen for this problem in the final release of VS 2005, the machines had the .NET Framework 1.1 installed, and the version of %windir%\system32\mscoree.dll was 1.1.4322.573 or 1.1.4322.2032.  When VS setup tried to install assemblies to the GAC, it failed because Windows Installer tried to call into a 2.0-specific API from mscoree.dll (needed because there are new processor architecture attributes on VS 2005 assemblies that only 2.0 knows about).  Since the version of mscoree.dll on the system was 1.1, these API calls failed.  This issue is described in more detail in my 1935 troubleshooting guide if you are interested.

    The underlying problem was that VS setup detected that the .NET Framework 2.0 was already installed and skipped that prerequisite step.  However, the machine did not actually have the .NET Framework 2.0 installed, but instead only had the registry key that VS setup uses to detect whether or not the .NET Framework 2.0 is installed.  I found that the machines had the following orphaned registry key/value that VS setup uses to determine that .NET Framework 2.0 was already installed:

    • Key name: HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727
    • Value name: MSI
    • Data type: REG_DWORD
    • Value data: 1

    Once the customers deleted this key/value and re-ran VS 2005 setup, it detected that it needed to install the .NET Framework 2.0, and after installing that, VS setup worked perfectly.

    As a side note if you're really interested, you could use some of the setup reverse engineering tricks that I describe here to determine the exact location of this registry key.  In this case, the key/value are listed in the [gencomp18] section of the file named baseline.dat in the setup subdirectory of the VS 2005 DVD or in the self-extracting setup package for the Express Editions.


  • Aaron Stebner's WebLog

    Update Rollup 2 setup failure while installing KB891593


    I have heard from a couple of customers who have encountered an error during setup for Update Rollup 2 for Media Center 2005, and setup then fails with a generic message (which simply states that setup failed).  In the cases I have seen so far, one of the prereqisite packages for Update Rollup 2 (a DShow hotfix described by KB891593) failed to install because there was another hotfix installed that updates the same file (another DShow hotfix described by KB904706).

    This does not happen on all computers that have KB904706 installed before attempting to install Update Rollup 2, but since it has been seen by multiple people now I wanted to post a workaround here just in case anyone else runs into it.

    How do I know if this issue is the one affecting my machine?

    You can diagnose this issue by looking at a couple of the log files that Update Rollup 2 setup creates.  First, you can open %windir%\mcsetup.log in a text editor such as Notepad.  If KB891593 is the package that fails on your system, you will see the following entry in mcsetup.log:

    Generic Package:   09/20/05. 09:00:44
    Looking for existing install of the generic package
    Creating Process: WindowsXP-KB891593-x86.exe /quiet /norestart
    Process returned 0x00000643

    The 0x00000643 return code (which translates to 1603 in decimal) represents the return code for a generic error in a Windows hotfix package.

    Now, you can look at %windir%\kb891593.log to determine the exact reason why this hotfix failed to install.  In the cases I have seen so far, the error in kb891593.log looks like the following:

    3.437: DoInstallation: Installation was canceled because migration is blocked by following files:
    3.437: Package KB904706, File c:\windows\system32\dllcache\quartz.dll, Version 6.5.2600.2749, Branch SP2GDR
    3.437: Package KB904706, File c:\windows\system32\quartz.dll, Version 6.5.2600.2749, Branch SP2GDR
    3.453: KB891593 Setup encountered an error:  Failed to migrate dependent packages.

    How can I workaround this issue?

    In the cases I have seen so far, uninstalling KB904706 and then attempting to reinstall Update Rollup 2 has proven successful.  The following steps can be used to accomplish this:

    1. Go to the Control Panel and choose Add or Remove Programs
    2. Check the box labeled Show updates in the top middle of the Add or Remove Programs window
    3. Locate the section named Windows XP - Software Updates and choose to uninstall the package named Security Update for Windows XP (KB904706)
    4. Attempt to install Update Rollup 2 again by returning to Windows Update or running the setup package located here

    Note: Once you have successfully installed Update Rollup 2 for Media Center 2005, you can safely reinstall KB904706 on your system if you would like to.

    What is the root cause of this issue?

    We are still trying to identify an exact root cause for this problem.  Both KB891593 and KB904706 try to update the file %windir%\system32\quartz.dll, but there is a mechanism within the Windows hotfix setup wrapper (update.exe) that accounts for overlapping files and migrates copies of the file appropriately.  We have attempted to reproduce this issue in our test lab and in the cases we have tried, Update Rollup 2 setup succeeds, and there is information like the following in kb891593.log:

    30.891: MigrateHotfix: Migrating hotfix KB904706
    30.922: Migrating QFE KB904706 with command line: update.exe -Z -Q -B:sp2qfe
    46.500: MigrateHotfix: Hotfix KB904706 successfully migrated
    46.500: MigrateHotfixes: Return code: 3010

    I will update this post if/when we discover better information about what is causing this problem and why it is not does not reproduce 100% of the time when we try it in our lab.

    <update date="2/21/2006"> Added a note that it is safe to reinstall KB904706 after Update Rollup 2 has been successfully installed if you run into this scenario </update>


  • Aaron Stebner's WebLog

    How to workaround errors installing .NET Framework 2.0 that are caused by registry permission problems


    I have had a few customers report problems installing the .NET Framework 2.0 with the following symptoms:

    • .NET Framework 2.0 setup fails and rolls back with no specific error message, just a generic "setup failed" message at the end
    • The action that fails is "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\regtlibv12.exe" "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\mscoree.tlb" or "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\regtlibv12.exe" "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\mscorlib.tlb" (you can find the error by using the steps described here)
    • The error code listed in the log file %temp%\dd_netfx20msi*.txt is 8002801c

    Examples of this problem are the comments located here and here, and the Product Feedback Center bugs located here and here and here.

    The underlying problem is that the Administrators group somehow was only granted read permission to some of the registry keys under HKEY_CLASSES_ROOT on these machines.  When the .NET Framework setup tries to register type libraries, it needs to create some new values under HKCR and it fails because of a lack of permissions (8002801c means "error accessing the OLE registry").  I have been able to confirm that this is the problem by having one of the customers use RegMon, but I haven't been able to figure out how the permissions got modified to be this way.  Up until now I also haven't been able to figure out how to fully reset the permissions so that .NET Framework setup will work.

    Fortunately one of the customers who had this problem contacted us with a solution that worked for them, and I wanted to list it here in case others run into this same problem in the future.  Here are the steps to follow to repair permissions to workaround this issue:

    1. Download the SubInACL tool from this Microsoft site and install it.  By default it will install to c:\Program Files\Windows Resource Kits\Tools
    2. Go to the Start menu, choose Run and type cmd
    3. Type cd /d %ProgramFiles%\Windows Resource Kits\Tools to change directories to the folder that SubInACL is installed to
    4. Type notepad reset.cmd and press yes to create a new file named reset.cmd in c:\Program Files\Windows Resource Kits\Tools
    5. Copy and paste the following contents into reset.cmd and then save and close it (or download it from here and rename it from reset.cmd.txt to reset.cmd):
      subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f
      subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f
      subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f
      subinacl /subdirectories %SystemDrive% /grant=administrators=f
      subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=system=f
      subinacl /subkeyreg HKEY_CURRENT_USER /grant=system=f
      subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=system=f
      subinacl /subdirectories %SystemDrive% /grant=system=f
    6. Type reset.cmd and press enter to run the SubInACL tool (you will need to have adminstrator privileges for this to run correctly).  This tool will take several minutes to run
    7. After reset.cmd completes, try to install the .NET Framework 2.0 or VS 2005 again

    Hopefully this will help.  If you try this and still have trouble getting setup to work correctly for the .NET Framework 2.0 or VS 2005, please contact me.


  • Aaron Stebner's WebLog

    Content protection errors in Update Rollup 2 for Media Center 2005


    I have heard of several folks running into issues playing protected content (such as purchased songs/movies, or HBO television shows) after installing Update Rollup 2 for Media Center 2005.  As I described here, Update Rollup 2 installs an updated Digital Rights Management (DRM) redistributable package.  We are still investigating reports of content protection problems in order to identify root causes and provide fixes.  In the meantime, I wanted to offer some suggestions.

    First, I highly encourage you to backup your licenses for protected content prior to installing Update Rollup 2.  You can do the following to backup licenses:

    1. Open Windows Media Player
    2. On the Tools menu, select Manage Licenses
    3. (optional) To change the backup location, click Change and then select a location where you want to store backup copies of your licenses
    4. Click Back Up Now

    Note - there are some license issuers that will not allow you to store backup copies of their license files, so this backup process may not back up all licenses on your system.

    Second, if you have already installed Update Rollup 2 without backing up licenses, and you are now unable to play protected content there is a knowledge base article that describes how to reset the DRM system on your computer.  There is one step that should be added to that article that is not there currently - before deleting the Windows Media DRM folder, you need to close any programs that might be holding files in that folder in use.  Specifically, make sure to close Media Player and Media Center, and run the command net stop ehRecvr to stop the Media Center Recording service immediately prior to trying to delete that folder.

    Resetting DRM restores the ability to play protected content in most cases.  However, if you use these steps to reset the DRM system and do not have backup copies of your licenses, you will lose the ability to play any previously acquired protected content.  If you have content that you do not want to lose, I would encourage you to wait until we can identify and post a fix.  If you are not concerned about any previous content, I encourage you to try out the steps in the KB article - they are semi-complicated, but I have used them in the past and had some success.

    There is a new hotfix available as of 4/14/2006 that is designed to fix protected content playback issues in Update Rollup 2 for Media Center 2005.  Please try out this hotfix if you have DRM/protected content playback issues in Update Rollup 2.

    <update date="11/4/2005"> Added an additional step for the knowledge base article - stopping any processes that may have DRM files in use </update>

    <update date="4/15/2006"> Added a link to a new DRM hotfix that is now available in case people find and read some of my older blog posts in an attempt to fix this type of issue </update>


  • Aaron Stebner's WebLog

    Visual Studio 2005 previous beta removal tool


    Hey all, I'm sorry for the delay posting this.  I've got a version of the cleanup tool that I wrote that I specifically tailored to automate that long list of removal steps listed here and here.

    You can download and try out the VS 2005 beta removal tool by going to this link.

    Note that this tool isn't "officially" supported by Microsoft or me.  That being said, please let me know if you have any trouble getting this to work on your computers.  My next step is to create a version of this tool that will automate all of the manual removal steps for the .NET Framework 2.0.  Stay tuned....

    As a side note, I was hoping to have it ready when VS 2005 and .NET Framework 2.0 beta 2 went live on Sunday, but obviously that didn't happen.  I apologize to the folks who have contacted me with broken machines and wasted days cleaning them up (and also those who have gotten burned by the manual uninstall but haven't contacted me).  I know it is not really any consolation now, but we're really working hard to do what we can to fix any broken machines without forcing you to reformat and also to get any of the underlying setup bugs fixed by the time VS 2005 ships.  Thank you for your patience and interest in VS 2005 and .NET Framework 2.0.


  • Aaron Stebner's WebLog

    How to short a Media Center remote control if it stops working correctly


    A couple of months ago, I posted a list of workarounds that have proven useful to resolve problems using the Media Center remote control and IR receiver after installing Update Rollup 2 for Media Center 2005.

    Since I posted that, I have received several comments from customers who were able to solve this issue with a different workaround not previously listed on that post.  I have found that internet searches do not do a great job of indexing blog comments, but they do well for the main body text of blog posts, so I wanted to post this suggestion as a separate blog post in the hope that others will be able to find it more easily.  I can't take any credit for finding this workaround.  It was posted as a comment on my previous blog post by a kind customer who discovered it and found it useful, and I have heard from several additional customers who indicated that it has helped them as well.

    I encourage you to try this workaround if you have already exhausted the list of suggestions located in my previous blog post and still have problems getting your Media Center remote control and/or IR receiver to work correctly.


    • Media Center only receives the first button press (for example - pressing up, up, up only goes up once, but pressing down, up, down, up will work correctly)
    • The IR receiver light does not blink when pressing a button
    • Pressing buttons on the remote do not have any effect


    Remove the batteries from the remote control and short the battery terminals using a small metal object such as a paper clip.

    There is enough capacitance remote control circuit board to keep it alive for hours even after you remove the batteries. However, you can workaround this and drain the capacitors by shorting two of the adjacent battery terminals on the remote.   Different remotes have different configurations, so it is difficult to know \which two adjacent terminals are the ones wired to the circuit board (the other two are simply a short to connect one battery to the other).  Therefore, you should short both pair of adjacent terminals, which can be achieved by using a paper clip.  After that, re-insert the batteries and try to use the remote control again.


  • Aaron Stebner's WebLog

    .NET Framework 3.0 setup log files


    The installer for the .NET Framework 3.0 (formerly named the WinFX runtime components) chains several different MSIs and Windows hotfixes behind the scenes.  If this setup fails, there are numerous possible causes due to the number of packages being chained behind the scenes.

    The following is a complete list of log files that can be produced during .NET Framework 3.0 setup.  This list may vary depending on what OS you are installing on, what processor architecture, and what prerequisite components were already installed on the system prior to running .NET Framework 3.0 setup.

    Logs produced by the .NET Framework 3.0 setup wrapper

    • dd_dotnetfx3install.txt
    • dd_dotnetfx3error.txt
    • dd_depcheckdotnetfx30.txt

    Logs produced by packages chained during .NET Framework 3.0 setup

    • RGB Rasterizer - dd_rgb_retMSI*.txt
    • MSXML 6.0 Parser - dd_msxml_retMSI*.txt
    • WIC - dd_WIC.txt
    • .NET Framework 2.0 - dd_netfx_retMSI*.txt
    • XPS - dd_XPS.txt
    • Windows Communication Foundation - dd_wcf_retMSI*.txt and dd_wcf_retCA*.txt
    • Windows Presentation Foundation - dd_wpf_retMSI*.txt
    • Windows Workflow Foundation - dd_WF_3.0_x86retMSI*.txt
    • Core .NET Framework 3.0 identity package - vsmsilog*.txt

    Logs produced by the .NET Framework 3.0 language pack setup wrapper

    • dd_dotnetfx3lperror.txt
    • dd_dotnetfx3lpinstall.txt 

    Logs produced by packages chained during .NET Framework 3.0 language pack setup

    • Individual .NET Framework 2.0 language pack MSIs - dd_netfx_retMSI_langpack*.txt
    • Individual .NET Framework 3.0 language pack MSIs - vsmsilog*.txt

    Log files will be located in the %temp% directory on the system during installation.  When setup completes successfully, the logs produced by the setup wrapper and the log file named vsmsilog*.txt are moved to a new folder located at %windir%\Microsoft.NET\Framework\v3.0\<product name>\Logs.  The <product name> will be Microsoft .NET Framework 3.0 or one of the language packs (for example - Microsoft .NET Framework 3.0 x64 Language Pack - FRA).

    If you run into any issues while installing the .NET Framework 3.0 and report issues to Microsoft via the product feedback site or the MSDN Forums, please locate and include any of the above log files if possible because it will make it easier for us to debug the failures and find root causes and workarounds.

    <update date="11/9/2006"> Added a list of log files for .NET Framework 3.0 language packs and a couple of other log files that I missed originally.  Also added locations where the logs can be found. </update>


  • Aaron Stebner's WebLog

    How to perform a silent repair and uninstall of the .NET Framework 3.5 and 3.5 SP1



    I have seen your blog posts that describe how to silently repair and uninstall the following versions of the .NET Framework:

    How can I perform a silent repair and uninstall for the .NET Framework 3.5 SP1?


    The following list provides example command lines that can be used to repair and uninstall the MSI-based .NET Framework 3.5 SP1 package after it has been installed on the system.  The silent option will perform the repair/uninstall with no UI displayed to the user.  The unattended option will perform the repair/uninstall with only a progress dialog, but with no user interaction required.

    .NET Framework 3.5 SP1 - silent repair

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /q /norestart

    .NET Framework 3.5 SP1 - unattended repair

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /qb /norestart

    .NET Framework 3.5 SP1 - silent uninstall

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /q /uninstall /norestart

    .NET Framework 3.5 SP1 - unattended uninstall

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /qb /uninstall /norestart

    Important notes about repair scenarios:

    • The .NET Framework 3.5.1 (an updated version of the .NET Framework 3.5 SP1) is installed as an OS component on Windows 7.  As a result, the MSI-based versions of 3.5 or 3.5 SP1 cannot be installed on these OS's, and the above command lines will not work on these OS's.  If you need to repair the .NET Framework 3.5.1 on Windows 7, you will need to use instructions like the ones in this blog post.
    • On Windows XP and Windows Server 2003, the .NET Framework 3.5 SP1 repair process will chain the repair processes for the .NET Framework 2.0 SP2 and the .NET Framework 3.0 SP2, so there is no need to use separate steps to repair those products if you are going to repair the .NET Framework 3.5 SP1 on these OS's.
    • On Windows Vista and Windows Server 2008, the .NET Framework 2.0 and 3.0 are OS components, and the repair of the .NET Framework 3.5 or 3.5 SP1 will not repair these OS components.  If you need to repair the .NET Framework 2.0 and/or 3.0 on Windows Vista or Windows Server 2008, you will need to use instructions like the ones in this blog post.

    Important note about uninstall scenarios:

    • The .NET Framework 3.5 SP1 uninstall process will only uninstall the .NET Framework 3.5 SP1 MSI.  It will not uninstall the .NET Framework 2.0 SP2 or the .NET Framework 3.0 SP2 products because there may be other applications on the system that rely on those versions of the .NET Framework.  If you want to uninstall the .NET Framework 2.0 SP2 and 3.0 SP2, you must uninstall in the following order:  .NET Framework 3.5 SP1, then .NET Framework 3.0 SP2 then .NET Framework 2.0 SP2.

    Other important notes:

    • Log files will be created for the .NET Framework 3.5 SP1 repair and uninstall just like for the initial install.  You can find a list of .NET Framework 3.5 and 3.5 SP1 log files in this blog post.
    • When calling .NET Framework 3.5 SP1 setup in silent or unattended mode, you should check the return code from the setup.exe process in order to determine success or failure.  Return code 0 means that the setup was successful, return code 3010 means that the setup was successful but a reboot is required to complete the setup and any other return code means that there was an error.  If you receive a 3010 return code, the reboot is required before all .NET Framework functionality will be expected to function correctly on the user's system, so it cannot be deferred forever.
    • The above examples only demonstrate the command lines used for repair and uninstall.  For install scenarios, I recommend reviewing the content in the .NET Framework 3.5 deployment guides as well as the steps for creating administrative install points.
  • Aaron Stebner's WebLog

    Uninstalling previous betas to prepare for VS 2005 and .NET Framework 2.0 RTM


    Now that the .NET Framework 2.0 and VS 2005 are officially released, those of you who have been running beta and CTP builds will need to prepare your machines to install the final release.  As I'm sure many of you are aware of if you've had a beta installed in the past, beta uninstall and migration to newer builds has been a very painful subject dating all the way back to VS 2005 and .NET Framework 2.0 beta 1.  Fortunately there is a lot more awareness that uninstalling the various pieces of VS 2005 is not trivial, and there are some automated uninstall tools and much better documentation.

    For those of you who will need to uninstall a previous beta in order to install the final release of VS 2005 and/or the .NET Framework 2.0, you should make sure to review the official uninstall instructions before starting to uninstall anything.  In case you read nothing else, please make sure that you leave the .NET Framework 2.0 beta uninstall until the very end.  Most of the other pieces of VS 2005 will not uninstall fully if you remove the .NET Framework 2.0 beta first, and that can cause problems in some scenarios after installing the final release.

    In order to make the uninstall process easier, there are a couple of automated uninstall tools available for various scenarios:

    1. Tool to uninstall beta and CTP builds of VS 2005 and .NET Framework 2.0 - this tool should be run on a machine that still has the beta or CTP build installed to uninstall all pieces of the beta or CTP to prepare a machine to install the final release
    2. Troubleshooting tool - this tool should be run to find and fix problems while running the final release of VS 2005 and .NET Framework 2.0 if you previously uninstalled in the incorrect order; this tool also has the automatic uninstall functionality built-in, but you should use the first tool if you only need to uninstall
    3. Tool to uninstall beta and CTP builds of WinFX - this is similar to the first tool, but is specifically designed to remove WinFX beta/CTP builds in addition to VS 2005 and .NET Framework 2.0 beta/CTP builds
    4. "The Hammer" - this tool is designed for scenarios where you have installed the final release of VS 2005 and/or the .NET Framework 2.0 and it does not work and the troubleshooting tool does not fix it; this tool will fully uninstall the final release of VS 2005 (in addition to any beta versions you might have installed) so make sure you only run it if you want to uninstall the final build; this tool is intended to be used to remove VS 2005 and get a machine back into a known state to try to install it again to clean up any problems that other troubleshooting steps are not able to resolve

    The uninstall tools (#1, #3 and #4 above) are designed to run Windows Installer APIs and command lines to discover whether or not a known, fixed set of products are installed and then remove them.  As we discover additional issues that these tools do not cover, I will be updating the troubleshooting tool.  The main goal of the troubleshooting tool is to fix up a machine that already has the final release installed without needing to have the user resort to uninstalling everything and starting from scratch.  It tries to perform more "surgical" fixes for specific issues related to incomplete/incorrect beta uninstalls.

    As always, let me know if you run into any issues or have any feedback on any of the above tools and I'll try my best to help.


Page 3 of 48 (1,191 items) 12345»