I posted a blog entry about a month ago about an issue that started appearing after customers install Update Rollup 2 for Media Center 2005.  Sometimes, while playing back live or recorded content, Media Center will stop displaying video and show a blue overlay screen with the text Digital Audio Service.  When I originally posted my previous blog entry, I had only heard from 2 people who were running into this issue, and both of them were able to resolve the issue by updating video and TV tuner drivers on their systems.  Since then, I have heard from many more people, and updating drivers has not helped in most cases (as you can see in the comments on that previous blog post).

Unfortunately, I don't have an exact root cause or fix to pass on yet, but I have been able to learn more about what we think is happening in these scenarios.  Some of this is still speculation because we are trying to reliably reproduce this issue in our test lab and are so far basing our investigation on the diagnostics reports that some of you have been kind enough to send me so far.

There is an algorithm in the stream buffer engine (SBE) that detects dropped frames and attempts to synthesize replacement frames to minimize glitches and freezes while watching video from analog signals.  Once the dropped frame rate gets high enough, this algorithm stops being effective because there are not enough good frames to use to synthesize replacements from and we will halt video playback.  Media Center sets a threshold for dropped frames to decide when to stop trying to create replacement frames in this scenario.

The Digital Audio Service overlay message is a new message introduced in Update Rollup 2.  It is designed to catch and report low frame rates in DVB-T signals as opposed to letting the video glitch and freeze.  There is a different threshold that controls when Media Center decides to show this Digital Audio Service overlay than the threshold I previously described in the stream buffer engine for analog signals.  It appears that the threshold for this frame dropping rate is set lower than the frame rate threshold for the stream buffer engine for analog signals and therefore Media Center shows this error prematurely in some cases.

Possible causes for high dropped frame rates include the following:

• Outdated drivers
• Older tuner cards
• Non Media Center processes running on the system that are CPU-intensive (because processor time otherwise used to process video frames is being spent elsewhere)
• Weak signal strength

In cases where the Digital Audio Service overlay appears, you will see that playing back the same video in Windows Media Player will work because WMP does not have this frame replacement algorithm or varying thresholds.  However, it is likely that you will see some type of glitching around the same time in the video playback as you start seeing the overlay in Media Center.

The frame dropping thresholds that I mention above are all controlled within Media Center code, so unfortunately that means there is not a way to configure a registry setting to make the Digital Audio Service overlay appear less frequently or never.

We will be spending more time trying to isolate a repro case and determine possible fixes or workarounds for this issue and I will post additional updates as I get them.

I mentioned yesterday that there is a new Windows Media Player hotfix (KB910393) available that will help reduce instances of digital rights management problems in Update Rollup 2 for Media Center 2005.

We have found a problem with the way the setup package for this hotfix interacts with Update Rollup KB908250 for Update Rollup 2 that can cause Media Center to crash when you try to launch it after installing KB908250 and KB910393 from Windows Update.

Problem description

In this scenario (described in this newsgroup posting), after installing Update Rollup 2 for Media Center 2005 you can visit Windows Update to search for additional updates.  There will be some new critical updates available that are only offered after you install Update Rollup 2.  Included in this list of critical updates are both KB908250 and KB910393.  If you accept the default settings, Windows Update will silently install each of these hotfixes and then reboot at the end.  However, after the reboot, you will get an unhandled exception and Media Center will crash if you try to launch it.

How to workaround the problem

In order to repair your system and fix this crash, you can one of the following sets of steps:

1. Download KB908250 and re-run it
2. Reboot

-or-

1. Click on the Start menu, choose Run and type cmd
2. Run the command %windir%\system32\spupdsvc.exe /install "Enables Service Pack Installer to complete its scheduled post-reboot tasks"
3. Reboot the system

Root cause

The reason Media Center crashes in this scenario is that the computer is left in a state where critical Media Center services (ehRecvr and ehSched) are not registered on the system.  The setup package for KB908250 runs commands to unregister these services, and then schedules a process to re-register them after the system is rebooted.  However, there is a command in the setup package for KB910393 that un-schedules the process that KB908250 schedules.  Therefore, the command to re-register Media Center services after the reboot never happens.

You can verify that you are running into this exact problem by checking the following:

• Run sc query ehrecvr and verify that it reports that ehrecvr is not an installed service on your system
• Run sc query ehsched and verify that it reports that ehsched is not an installed service on your system
• Look for a file named %windir%\system32\spupdsvc.inf and verify that it contains a [ProcessesToRunAfterReboot] section with commands to run C:\WINDOWS\ehome\medctrro.exe /p /f C:\WINDOWS\INF\KB908250rg.inf RunOnce, C:\WINDOWS\ehome\EhMCXIns.exe /i and C:\WINDOWS\system32\spupdsvc.exe /delete

This problem will only occur if you install KB908250, suppress the reboot at the end, and then install KB910393 afterwards.  Unfortunately, this is exactly the way that Windows Update currently installs these 2 hotfixes after Update Rollup 2 is installed.

We are still working with the Windows Update and Windows Media Player team to identify the best way to fix this issue.  I will post an update when we decide the right course of action.  I apologize for the inconvenience that this issue is causing.

I previously described a scenario where installing Media Player 10 on top of Update Rollup 2 for Media Center 2005 can cause errors playing back content that is protected by digital rights management (DRM).  We are still working on a fix that will repair the DRM store on machines that are already in a bad state, but in the meantime there is an additional hotfix (KB910393) that just became available that will prevent Media Player 10 from allowing you to install and revert DRM files.

You can download that hotfix at this location, and it will also be offered as a critical update to Media Center systems that have Update Rollup 2 installed if you visit Windows Update.

I know I'm a little late in providing a link to this, but I still wanted to mention here that there is a new community tech preview (CTP) version of WinFX available for download.  This November 2005 CTP is built against the final released version of the .NET Framework 2.0, so it will be compatible with the final release of Visual Studio 2005 and SQL Server 2005.  That means that this CTP will be the last time you have to uninstall and reinstall builds of the .NET Framework 2.0, VS 2005 or SQL 2005 in order to get WinFX development scenarios to work correctly on your system. 

Unfortunately, the November 2005 CTP of WinFX is not compatible with previously released CTP builds of Windows Vista because those Vista builds include a prerelease version of the .NET Framework 2.0 installed as part of the OS, and you cannot update an OS component to a later version using the MSI-based installer for the .NET Framework 2.0.  Also, the November 2005 CTP is not compatible with any beta versions of VS 2005 or SQL Server 2005 that you might still have installed because you can only have one build of the .NET Framework 2.0 installed on your system at any given time.  You can use this removal tool to uninstall incompatible beta builds of VS, SQL Express, and WinFX.

Tom Archer posted a really nice list of links and an FAQ with more information about uninstalling previous WinFX CTP builds and installing the November 2005 CTP.  Karsten Januszewski also posted this item with a description of what is new in the November 2005 CTP, including a draft MSDN document.  I encourage you to check out both of these pages for more info about the WinFX November 2005 CTP.

I have heard from a few folks (mostly via comments on this blog post) regarding an issue with HP Media Center 2005 machines.  On some HP machines, customers are seeing an error message pop up when launching Media Center.  This error message has the following information:

• Title:  Windows - No Disk
• Text:  There is no disk in the drive. Please insert a disk into drive
• Buttons: Cancel, Try Again and Continue

This error does not prevent Media Center from launching, but sits on the desktop until you exit Media Center.

We were able to track this issue down to some kind of bug in the HP Image Zone for Media Center application that is pre-installed on HP Media Center systems that appears if you uninstal the Norton Anti-virus and/or System Security suite that also comes pre-installed on HP Media Center systems.  We reported this issue to HP and also some customers have reported it, and they have issued an update to Image Zone that addresses this issue.

A customer was kind enough to post the response he received from HP about this issue.  According to the HP support team, you can find this update for Image Zone at this location, and that should allow you to resolve this No Disk error without needing to reinstall Norton or uninstall Image Zone (which are the possible workarounds suggested in the past).

<update date="11/30/2005"> HP contacted me today with a new location for the fix, so I have updated the link in the text of this blog post </update>

<update date="4/9/2006"> The previous link I had posted seemed to be unreliable for some people because it was pointed to the HP FTP server, so I have updated it to a better link location. HP also appears to have updated the package since I originally posted this as well to provide some additional fixes. </update>

I heard from a customer and a Microsoft employee asking how to register new assemblies so that they will be listed in the Add References dialog in Visual Studio 2005.  I have always done this in the past by using the Browse button and finding a copy of the assembly on my local drive, so I did a bit of research to try to figure out how to pre-populate assemblies in the list for the Add References dialog.

Unfortunately, installing the assembly to the GAC does not automatically populate it into the Add References dialog, even in Visual Studio 2005 (and this despite the fact that this MSDN document claims that assemblies in the GAC will be listed in VS 2005).

Here are some options I found that worked for me when I tried them on my machine:

1. Add a new sub-key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx (or the same sub-key under HKEY_CURRENT_USER if you want the assemblies to appear only for the current user instead of all users).  The default value of the sub-key should be the folder path that you want Visual Studio to look in for assemblies to include in the Add References dialog.  This registry path is specific to VS 2005 and the .NET Framework 2.0 and will not work for previous versions of VS or the .NET Framework.  It is documented in this MSDN document.
2. Add a new sub-key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders (or the same sub-key under HKEY_CURRENT_USER if you want the assemblies to appear only for the current user instead of all users).  The default value of the sub-key should be the folder path that you want Visual Studio to look in for assemblies to include in the Add References dialog.  This registry path is global and any folders listed here will be processed by VS .NET 2002, VS .NET 2003 and VS 2005 as well as the .NET Framework 1.0, 1.1 and 2.0.  It is documented in this KB article.
3. Place a copy of the file in the folder c:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PublicAssemblies.  This path is dependent on the version of Visual Studio that you have installed and whether or not you installed it to the default path, so you may need to adjust it as needed for your system.  The path that I list is for a default install of VS 2005.

I am not an expert in populating the Add References dialog, and this list is mostly intended to be a list of options that I discovered that worked correctly when I tried them out in my limited scenarios.  If you need to add assemblies to the Add References dialog, it appears based on my research that the options I listed above are in the order of preference.

In other words, you should use the AssemblyFoldersEx registry value if it is feasible for your scenario.  If that is not possible because you are running VS 2002 or 2003 or want to add your assembly to the Add References dialog in all versions of Visual Studio instead of just a specific version, then you should use the AssemblyFolders registry value.  If there is some reason you cannot use either of those registry values, copying your files to the PublicAssemblies folder will also work, though that is not the recommended approach.

<update date="11/29/2005"> Adding more detailed information about recommendations for which option to choose </update>

A couple of folks have reported issues to me via my blog about errors downloading television guide data in Media Center 2005 when they install a SonicWALL firewall device on their network.  Our guide download team has debugged this issue on a Media Center system that a Microsoft employee reported this problem on and found the following:

SonicWALL has an option in one of their settings pages (diag.html) which allows you to enable or disable HTTP byte range requests as part of the gateway anti-virus filtering process.  If that setting is turned off (which it is by default on the SonicWALL device we debugged on), then guide downloads will not work within Media Center.

If you have a SonicWALL device on your network and cannot get guide download to work, you can use the following steps to resolve this issue:

1. Navigate to http://<your_router_IP_address>/diag.html from a computer on your network (by default this URL will be http://192.168.168.168/diag.html)
2. Enable the setting to allow HTTP byte range requests in the gateway anti-virus filtering process
3. Reboot the SonicWALL firewall device
4. Attempt to download guide data within Media Center again

The underlying cause for this issue is that the guide download service in Media Center relies on the background intelligent transfer service (BITS) in Windows, and the BITS service requires the ability to request and receive byte ranges to support key scenarios involving data throttling and download restarting.

As Quan briefly mentioned in this blog post, there is an issue with uninstalling the beta versions of the VS 2005 Express Editions if you did not register your copy of the beta Express Edition prior to trying to uninstall it.  If you are uninstalling an Express Edition using the Add/Remove Programs entry, you will see setup hang on the progress page, so it is easy enough to see if you ended up in this state.  However, if you use the automatic uninstall tool to remove VS 2005 beta products, you will not see any progress UI because the uninstall tool runs Express Edition uninstall in silent mode.  In this case, it will appear as though the uninstall tool is running and not doing anything.

In order to work around this issue, you use the following steps while Express Edition uninstall is in progress:

1. Click on the Start menu, choose Run and type taskmgr
2. Go to the Processes tab
3. Search for the executable name for the Express Edition you have installed that is currently being uninstalled (see list of executable names below)
4. Highlight the executable name, click End Process and click Yes to confirm that you want to kill the process

These steps will cause the Express Edition uninstall to become unstuck and skip past the custom action that hangs if the product was not registered.  This will result in some files being orphaned after uninstall completes, but they will not harm anything once you install the final release of VS 2005.

When looking in Task Manager, the executable names will be the following depending on what Express Edition(s) you have installed:

• Visual Basic 2005 Express Edition - vbexpress.exe
• Visual C# 2005 Express Edition - vcsexpress.exe
• Visual C++ 2005 Express Edition - vcexpress.exe
• Visual J# 2005 Express Edition - vjsexpress.exe
• Visual Web Developer 2005 Express Edition - vwdexpress.exe

Also, if you ran uninstall from Add/Remove Programs, you can use the following steps instead of killing the executable in Task Manager:

1. Cancel the uninstall process
2. Launch the Express Edition and choose to Register it from the Help menu
3. Re-run uninstall and it should no longer hang

I have heard from a few customers who have run into some strange behavior in the Visual Studio IDE after uninstalling previous beta versions and installing the final release of Visual Studio 2005.  They have reported seeing issues including (but not necessarily limited to) the following:

• Visual Studio shows an error message stating that it cannot open "C:\Documents and Settings\<user>\My Documents\Visual Studio 2005\Settings\currentsettings.vssettings" for writing
• Launching Tools | Import and Export Settings... and choosing any of the radio buttons results in an error message stating "Error 1: Reset/Export/Import was interrupted by the user".
• Keyboard shortcuts fail to work correctly in the Visual Studio IDE

For the customers I have worked with so far, the following steps have resolved this issue:

1. Close all instances of the Visual Studio IDE
2. Click on the Start menu, choose Run and type cmd
3. Type "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\devenv.exe" /resetuserdata (this command assumes that you have installed VS 2005 to the default path, so you will have to modify this command line if you installed to a non-default path)
4. Wait 1-2 minutes for the devenv.exe process to finish.  You can use Task Manager to verify that the process has completed
5. Restart the Visual Studio IDE

Now that Visual Studio 2005 has shipped, I've gotten a couple of questions from customers wondering why they are able to uncheck the J# language tools item in the Visual Studio setup tree and yet setup still installs the J# redistributable package 2.0.  I partially addressed this issue in a previous blog post back when VS 2005 beta 2 shipped.  The same underlying design that I described in that post exists in the final release of VS 2005.  Essentially, the algorithm for deciding whether or not to install the J# redistributable is the following:

1. Setup looks at the file baseline.dat and finds the J# redistributable package 2.0 item represented by the section titled [gencomp68]
2. The [gencomp68] section contains the value ComponentType=3, which means that it is a chained package that will be conditionally installed after the main VS 2005 MSI depending on what features are chosen in the setup feature tree
3. The [gencomp68] section contains a list of GUIDs in the value DependentFeatures that represent FeatureID values in the Feature table of the main vs_setup.msi
4. Setup iterates over that list of GUIDs and if it detects that any of the features represented by those GUIDs are selected to be installed as part of VS 2005, it adds the J# redistributable package v2.0 to the list of items that need to be installed after the main VS 2005 MSI is done installing

Now, if you take a look at the baseline.dat file in a text editor and locate the list of GUIDs, you can search for those values in the Feature table of the VS 2005 MSI, you can see that if the J# or Visual Web Developer language tools features are selected during setup, the J# redistributable will also be installed for you as a chained component.

The next question that has come up is one that I haven't addressed in that previous blog post - why does Visual Web Developer require the J# redistributable?  At a high level, the answer is that you are able to develop web applications in any number of programming languages, including J#, so therefore the J# redistributable is installed in case you decide to develop your web applications in J#.

That answer leads to one additional question - why can't you just install Visual Web Developer C# support or something like that if you know ahead of time that you are not planning to develop web applications in J#.  If you look at the feature tree for VS 2005 setup, you will see a single item under Language Tools named Visual Web Developer.  However, this feature is not sub-divided any further, so it is not currently possible to install only the pieces required to install Visual Web Developer C# support, Visual Web Developer VB support, Visual Web Developer J# support, etc.  We determined while developing VS 2005 that it would be very time-intensive and error-prone to try to sub-divide the Visual Web Developer features on a language-by-language basis, and that it would only have questionable benefit to the end user.  Therefore, we had to make a trade-off and the decision was made to live with the side effect of installing the J# redistributable package if the user chooses to install Visual Web Developer during VS 2005 setup (even if the user does not choose to install the J# language tools).  Essentially, we decided that the benefit was not worth the cost, and that we had already noticeably improved the setup behavior related to the J# redistributable from the VS 2003 product (I described the VS 2003 behavior and the background behind why it behaved that way in this post).

I have heard from 2 customers this past week who were trying to pre-install the .NET Framework as part of the T13 phase of OS setup (in their cases, Windows XP).  They were including the .NET Framework 2.0 setup command line in svcpack.inf and then copying svcpack.inf into the i386 directory of their OS install location.  Their svcpack.inf looks similar to the following:

[Version]
Signature="$Windows NT$"

[SetupData]
CatalogSubDir="i386\svcpack"

[ProductCatalogsToInstall]

[SetupHotfixesToRun]
dotnetfx.exe /Q /C:"install.exe /Q"

However, both customers found that the .NET Framework 2.0 setup failed in this scenario.  The error in the verbose MSI log file for .NET Framework 2.0 setup is the following:

Error 1406.Could not write value DW0200 to key \Software\Microsoft\PCHealth\ErrorReporting\DW\Installed.  System error .  Verify that you have sufficient access to that key, or contact your support personnel.

One of the customers worked around this first error by deleting the DW key during OS setup before installing the .NET Framework 2.0.  However, when doing this, they then encountered the following error:

MSI (s) (9C!A8) [23:03:15:484]: Product: Microsoft .NET Framework 2.0 -- Error 25007.Error occurred while initializing fusion. Setup could not load fusion with LoadLibraryShim(). Error: The handle is invalid.

Unfortunately, I don't know of a way to workaround this second error.

This scenario used to work with .NET Framework 1.0 and 1.1 setup, but it has been broken by some of the changes made to setup in .NET Framework 2.0 (the registry key listed above and the custom action to install assemblies are both new in .NET Framework 2.0 setup).

I don't have much experience with customizing OS installations using the various methods that are available, so I asked these customers why people might want to use svcpack.inf to install the .NET Framework as part of OS setup as opposed to other methods that have been shown to work for the .NET Framework 2.0 (such as using the GuiRunOnce section of winnt.sif or setting a RunOnceEx registry value to launch .NET Framework 2.0 setup on first boot of the OS).  Here is what they told me:

1. Many prefer using svcpack.inf because it allows them to avoid setting OEMPreinstall=Yes in winnt.sif, which breaks F6 functionality for mass storage drivers
2. It was common with the .NET Framework 1.0 and 1.1 because it worked reliably, and installing it through svcpack.inf meant it would alread be installed so that other setups that rely on the .NET Framework will also install correctly afterward

I am going to try to look into possible workarounds to get .NET Framework 2.0 setup to work when launched by svcpack.inf in the T13 phase of OS setup.  However, for now, please be aware of this limitation and update your OS install scripts accordingly.  In addition, if this scenario is important to you, please go to the bug form for this issue on the MSDN product feedback site and click on the link to vote on this bug so that the product team will better understand the importance of making this type of scenario work.

Also, if anyone has any tips and tricks that can be used to get this to work, please post a comment on this blog post or contact me and let me know.

I have heard from and read about problems reported by several customers who are running into package load failure errors in the Visual Studio IDE after migrating from beta or CTP builds of Visual Studio 2005 and the .NET Framework 2.0 to the final release.  I previously posted this blog item with some suggestions about how to resolve this.  I finally found a machine inside of Microsoft that reproduced the same symptoms and was able to track down another possible root cause and fix that the current cleanup tools do not seem to handle in all cases.

The machine I looked at today had some orphaned beta assemblies in the GAC.  Because those were present, the native images generated during setup for the final release of VS 2005 contained references to these orphaned assemblies.  Then, when the VS IDE attempted to load packages at startup, it started loading these native images with invalid references in them and failed with one of the infamous Package Load Failure error dialogs that looked like the following (the exact package that fails to load will vary, but the rest of the dialog will look similar to this):

I had to close Visual Studio and then run the following command line to clear up these package load failures:

rd /s /q %windir%\assembly\NativeImages_v2.0.50727_32\Microsoft.VisualStu#

If you are running into package load failures on your system after installing the final release of Visual Studio 2005, I encourage you to first try the troubleshooting tool, and then try the above command line.  If all of those fail, then please proceed to step 3 in this blog post (which I've also updated to include this command line as step 2).

If you try to extract the contents of the .NET Framework 2.0 setup package and install it using the MSI directly, you will see a blocking dialog that looks like the following:

This type of blocking dialog does not appear when trying to install the .NET Framework 1.0 or 1.1 using the MSI directly.

If you look at the .NET Framework 2.0 netfx.msi in Orca, you can see that there is a custom action that starts with the name CA_BlockDirectInstall_GUIH_SKU_URT.  Then, if you look at the InstallExecuteSequence table of the MSI, you will see that this custom action has the following condition: ( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1)  ) AND ( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1)  ).  As you can see from these conditions, this custom action will fire and show this block dialog unless one of those properties is passed on the command line or the product is already installed.

As I previously described in this blog post, we created a new external UI handler for the .NET Framework 2.0.  Along with this external UI handler, we added this custom action to block the user from installing via the MSI directly as a means of more strongly encouraging people to install using the external UI handler (side note  - this is the technique described in this post on the Windows Installer team blog for using external UI handlers).

The external UI handler for the .NET Framework 2.0 includes a command line parameter (described in this previous post) to invoke administrator mode - you can enter this mode by running install.exe /a.  This administrator mode is essentially a UI wrapper around the standard msiexec.exe /a command line parameter for creating an administrative install point (AIP) for an MSI.  It requires you to accept a EULA, then allows you to specify a location to stage the files for the administrative install point.  The interesting thing is that if you run install.exe /a and then look at the verbose MSI log file (named %temp%\dd_netfx20_a_msi*.txt), you will see that the property ADDEPLOY=1 is set while creating the AIP.  However, this property is not used at all during creation of the AIP, and it is not saved as a part of the staged MSI.  Therefore, even if you try to install the .NET Framework 2.0 using the AIP created using install.exe /a, you will still run into the block dialog shown above.

To make a long story short, you can use the following command lines to create an administrative install point and install the .NET Framework 2.0 using the MSI directly:

1. To extract the contents of the setup package - dotnetfx.exe /t:c:\temp /c (or you can substitute any path of your choosing for c:\temp)
2. To create an administrative install point - c:\temp\install.exe /a
3. To install using the MSI directly - msiexec.exe /i netfx.msi ADDEPLOY=1

If you are interested, you can combine the steps above if you do not care about being able to extract the contents of dotnetfx.exe or create an administrative install point:

• To combine steps 1 and 2 above to create an administrative install point without extracting dotnetfx.exe first - dotnetfx.exe /c:"install.exe /a"
• To combine steps 1, 2 and 3 above to directly install the MSI - dotnetfx.exe /q /c:"msiexec.exe /i netfx.msi ADDEPLOY=1 /qn"

One other item I should point out here - you will also notice when you install the MSI directly with basic UI (using the /qb switch instead of the /qn switch above), the progress dialog has a title bar and a cancel button but is otherwise blank like the following:

The .NET Framework 2.0 MSI has been configured to be language-neutral (described in more detail here if you're interested), and there is a bug in Windows Installer that when a language-neutral MSI with no action text or error text is installed in basic UI mode, it will not display any of the standard messages in the progress dialog.  Unfortunately, this bug is present in all current versions of Windows Installer up to and including version 3.1.  I tried an installation scenario using basic UI mode on a recent Windows Vista build and verified that this bug has been fixed in Windows Installer 4.0 (which is included in Vista).

One final thing - all of the details in this blog post apply to all .NET Framework 2.0 and VS 2005 products that use the new external UI handler we have created.  This includes the .NET Framework 2.0 SDK, the J# redistributable package, the VS Tools for Office Runtime, Document Explorer, etc.  Essentially, any setup package included as part of Visual Studio that is packaged as a self-extracting executable and contains install.exe, install.ini and install.res.####.dll will behave the same way.

I realize this topic is a bit involved and confusing and represents a change from previous versions of the .NET Framework, so please let me know if you have any questions or run into any problems getting things to work for you.

I learned a cool trick last week that might be useful if you are running into issues while using the built-in Sonic CD/DVD burning software in Media Center 2005.  The following steps will enable creation of a log file for debugging purposes:

1. Click on the Start menu, choose Run and type notepad %windir%\ehome\createdisc\soniclog_mce.log
2. Click Yes to create a new file in this location
3. Close Notepad and click Yes to save the file

Once you have created this file, any subsequent times that you use Sonic burning functionality inside of Media Center, it will write to this file.  This file has to already exist before Sonic will write to it however, so it will not log any error information until you manually go and create a new file with the expected name in this location.

If you run into any issues with CD/DVD burning, please create this log file and include it when contacting me or your customer support representative.  I'd also encourage you to open up the log file and take a look at it yourself as well.  There are some errors that have relatively simple workarounds that can be determined simply by looking at the error log information.

Hope this helps....

We have gotten a knowledge base article written and published based on some of our findings regarding the component registration errors that some folks have seen while trying to install Update Rollup 2 for Media Center 2005.  You can find the article at this location.  This KB article covers the items I have previously written about in my blog here, here and here.

We are also working on updating the installation logic used by Windows Update to better detect this inconsistent .NET Framework installation state where .NET Framework 1.1 is installed but the version number of %windir%\system32\mscoree.dll is 1.0.3705.6018.  We hope to have this change tested and published in the near future so that future installations of Update Rollup 2 will not be susceptible to this problem.

I recently heard from a customer who lives in Spain and has been using Media Center 2005 for a while.  After installing Update Rollup 2 for Media Center 2005, they reported to me that they could no longer change the audio channel for their television shows from stereo to SAP because they could not find the Audio menu in the TV Settings menu on their system anymore.  After digging through the source code and asking around on the team a little bit, here is what I found out about this scenario:

In Media Center 2005, there was an Audio menu under Settings | TV.  This Audio menu contained an audio channel spinner that let you choose between stereo and SAP.  It also contained other spinners and text boxes that could be used to configure captioning for television shows.  The Audio menu was configured to always be displayed in the list of TV Settings menues, no matter what locale you lived in and configured your OS for.

In Update Rollup 2, the captioning settings have been broken out into a separate menu under Settings | TV.  This left the stereo/SAP spinner as the only item in the Audio menu.  Therefore, we added a condition to the Audio menu itself so it would be hidden in locales that did not support SAP.

In the case of this customer, they indicated to me that Spain technically does not support SAP, but they do support NICAM DUAL, which works roughly the same way to deliver alternate audio tracks for television shows.  However, Media Center treats Spain as a locale that does not support SAP and hides the Audio menu entirely.

I am not sure if there are any countries or regions other than Spain affected by this logic change in the Audio settings menu in Media Center 2005.  There is not any workaround to enable this menu in an affected country or region, but there are a couple of registry values that can be updated to cause Media Center to use the SAP audio channel instead of the default stereo channel.

You can click on the Start menu, choose Run, type cmd, and then run the following 2 commands in a cmd prompt to set the registry values necessary to enable the SAP audio channel in Media Center 2005:

• reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Media Center\Settings\VideoSettings" /v PreferredLanguageID /t REG_DWORD /d 1 /f
• reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Media Center\Settings\VideoSettings" /v SAPOn /t REG_DWORD /d 1 /f

Rob Mensching posted a blog entry last week that I wanted to make sure everyone reading my blog also sees.  In this post, he introduces a new tool in the WiX toolset called ClickThrough (which can be downloaded here).  ClickThrough is still in a relatively early phase of the development process, but the drop that is currently available has some pretty nice functionality:

• Graphical user interface for creating an MSI for an application designed to be distributed via the Internet (using WiX behind the scenes to represent and build the MSI)
• Self-extracting setup.exe that installs the MSI
• Update executable that polls an RSS feed to detect new versions of the application and then installs them automatically

The current version of ClickThrough is designed to install isolated, low impact applications - ones that are installed on a per-user basis and do not require administrative privileges to install.  Future iterations will address creating setup packages for other types of applications.

I've been playing around with ClickThrough a bit and have been able to use it to successfully create and deploy simple applications.  You may run into some bugs or usability issues or have some feature suggestions, and they can be reported here (for bugs) and here (for feature suggestions).  Keep in mind that Rob has posted a disclaimer at the top of his post about ClickThrough indicating that it is "just-post-prototype" and should not be used in production software yet.

As a side note, you'll notice if you download and install ClickThrough that it is installed and updated using ClickThrough itself, kind of like using the compiler to build the code for the compiler itself  :-)

I've talked to a few folks who work at Microsoft who have resolved issues installing the final release of Visual Studio 2005 and the .NET Framework 2.0 using some of my previous blog posts.  I realized that I've posted quite a few random tips and tricks for getting beta uninstall to work and final release setup to work over the past few weeks and months, and I usually know exactly where to find them and when they are applicable.  Unfortunately, the searching mechanism for MSDN blogs is not perfect, so it sometimes can be hard for others to find the information they need to resolve their setup issues.

As a result, I decided to post a new article that can serve as a central collection point for all of these tips and tricks.  You can click on the link to view the Visual Studio 2005 and .NET Framework 2.0 Setup Troubleshooting Guide.

As I create new blog posts, I will update this central article as well in order to try to make it as easy as possible to find information about Visual Studio 2005 and .NET Framework 2.0 setup issues.

I heard from a customer today who was running into component registration failure errors after installing Update Rollup 2 for Media Center 2005.  In this case, they tried the workaround for the .NET Framework issue described in this previous blog post, but it did not resolve the errors.  I found the following information in the file %windir%\medctrro.log that the customer sent me:

GACAssembliesAddRemove: Failed to uninstall assembly (Microsoft.MediaCenter)

Fortunately, I had seen a similar problem in the past where an add-in had installed a copy of Microsoft.MediaCenter.dll as part of their setup so I had an idea of where to start in troubleshooting this issue.  The file Microsoft.MediaCenter.dll is always installed on Media Center 2005 computers as part of the OS.  When an application that is packaged using an MSI-based setup is installed on the Media Center 2005 OS and it tries to install Microsoft.MediaCenter.dll (or any other assembly that is installed as part of the OS), it adds an additional reference count on the file.  Then, when Update Rollup 2 or any other Media Center hotfix tries to uninstall the old copy of this file from the GAC and then install the new copy of the file to the GAC, the uninstallation fails because of the additional reference count held on this file.  Media Center hotfix setup halts at the point of this failure, and the remaining registration steps are not run (including registering Media Center services such as ehRecvr and ehSched).

What I had the customer do was use the tool described in this blog post to run the msiinv.exe tool with the verbose switch (-v).  Then I searched for Microsoft.MediaCenter.dll in the output from msiinv.exe.  In the case of this customer, they had a product called Rudeo MCE Control installed.  I went to the company's web site and found a trial version of the Rudeo MCE Control.  Looking at the MSI for this product in Orca showed that it was indeed installing a copy of Microsoft.MediaCenter.dll to the GAC.

I had the customer uninstall the Rudeo MCE Control and then re-install Update Rollup 2 from this location and Media Center Hotfix KB908250 from this location to resolve these component registration failure errors.

If you run into this issue, you can re-install the Rudeo MCE Control software after you uninstall it and then install Update Rollup 2.  However, if there is any future Media Center hotfix that needs to update Microsoft.MediaCenter.dll, then you will have to uninstall the Rudeo MCE Control software before the future hotfix will install successfully due to the root cause described above.

I have heard from a couple of customers who have uninstalled beta versions of Visual Studio 2005 and then installed the final release.  After installation finished, they saw a small error dialog that looks like the following when trying to launch the Visual Studio 2005 IDE:

Pressing OK on this dialog dismisses the IDE and VS 2005 is not usable.

There are a couple of cases where registry data can be orphaned on the machine that causes this type of error.  Unfortunately, because this data is written by a custom action and there are some "interesting" conditions on that cusotm action in the VS MSI, running a repair of VS 2005 will not correctly fix the registry values that control this functionality.

The following steps can be used to resolve this Invalid license data error message:

1. Uninstall the Visual Studio 2005 product that you have installed.  You only have to uninstall the main Visual Studio product entry in Add or Remove Programs, and you can leave the other pieces installed by Visual Studio setup (such as the .NET Framework 2.0, MSDN, SQL Express, etc) alone.  The product name in Add or Remove Programs that you want to uninstall is dependent on the VS 2005 edition you have installed.  For example, for the English Professional edition, the product name will be "Microsoft Visual Studio 2005 Professional - ENU"
2. Click on Start, choose Run and type cmd
3. Copy and paste each of the following commands into the cmd prompt to clean up orphaned Visual Studio licensing data in your registry: 
   reg delete HKCR\Licenses\17A13F5F-2dE4-4691-B332-83CA4CC38935 /f
   reg delete HKCR\Licenses\2F1682F3-6A3C-4545-AF41-6836A22276CF /f
   reg delete HKCR\Licenses\2FE88699-A1AF-410D-8049-1CB6BA8F8FF2 /f
   reg delete HKCR\Licenses\5BCBC240-27DF-49C1-8C1C-27B8463009A9 /f
   reg delete HKCR\Licenses\895E2152-C3F9-4C49-968B-15B08ADA0F37 /f
   reg delete HKCR\Licenses\95C63E85-8244-4D86-8327-579B85EC154C /f
   reg delete HKCR\Licenses\BA32367F-28F8-4AEA-848D-95AE438B3B9C /f
4. If you are installing on a 64-bit OS, copy and paste each of the following commands into the cmd prompt to clean up orphaned Visual Studio licensing data in your registry:
   reg delete HKCR\Wow6432Node\Licenses\17A13F5F-2dE4-4691-B332-83CA4CC38935 /f
   reg delete HKCR\Wow6432Node\Licenses\2F1682F3-6A3C-4545-AF41-6836A22276CF /f
   reg delete HKCR\Wow6432Node\Licenses\2FE88699-A1AF-410D-8049-1CB6BA8F8FF2 /f
   reg delete HKCR\Wow6432Node\Licenses\5BCBC240-27DF-49C1-8C1C-27B8463009A9 /f
   reg delete HKCR\Wow6432Node\Licenses\895E2152-C3F9-4C49-968B-15B08ADA0F37 /f
   reg delete HKCR\Wow6432Node\Licenses\95C63E85-8244-4D86-8327-579B85EC154C /f
   reg delete HKCR\Wow6432Node\Licenses\BA32367F-28F8-4AEA-848D-95AE438B3B9C /f
5. Re-install the Visual Studio 2005 product that you uninstalled in step 1 above

After doing this, the license data should be recreated and correct and allow you to launch the VS 2005 IDE.

<update date="10/25/2006"> Added some more licensing registry values and a new section for 64-bit registry values that need to be removed </update>

<update date="8/27/2009"> Fixed broken link to image. </update>

I have heard from a couple of folks who have had trouble getting IR learning to work for their universal remote controls after installing Update Rollup 2 for Media Center 2005.

As I described in this blog post, Update Rollup 2 installs an updated set of IR drivers (via KB888795), among other things.  Unfortunately, there is a design flaw in the Windows driver installer - it will always writes this registry key anytime a new IR receiver device is enumerated by plug-and-play.  The IR rollup package that is installed as a prerequisite of Update Rollup 2 forces such an enumeration when it upgrade the IR drivers.  Also, this registry key can be overwritten if you plug in a new IR receiver.  Doing so will cause the new device to be enumerated by plug-and-play, and the driver installation overwrites the registry key.

Whenever IR drivers are updated (such as when you install Update Rollup 2), it is necessary to update a registry value to re-enable IR learning in universal remote controls.  You can do so by using the following steps to reset the necessary registry value and then rebooting your machine to cause it to take effect:

1. Click on the Start menu, choose Run, type cmd and click OK
2. Run this command:  reg add HKLM\SYSTEM\CurrentControlSet\Services\HidIr\Remotes\745a17a0-74d3-11d0-b6fe-00a0c90f57da /v EnableDebounce /t REG_DWORD /d 0 /f
3. Reboot to cause the change to take effect

I received a question from a customer today asking how they could update their Media Center television guide download time.  It had been set for 4:50am and they wanted to change it to some other time in order to not be woken up by a dialing modem sound.  I looked at the TweakMCE tool, but that didn't offer any configuration settings for guide download time.  Then I found the registry value that is used to control guide download time:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Service\EPG]
"dlRegTime"

Unfortunately, the value in question is a REG_QWORD, so it is very difficult to manually change it to a specific time of your choosing.  Fortunately, the customer found out that there is a tool that Peter Rosser wrote that lets you specify the exact time that you want guide downloads to happen.  You can read about and download a copy of his tool at this location.

Note that after you change the preferred Media Center guide download time, you will need to stop and restart the Media Center Scheduler service by running net stop ehsched and then net start ehsched (or if you'd prefer, by rebooting the computer).

<update date="11/14/2005"> Added note that ehSched needs to be stopped and restarted for the time change to take effect </update>

There is some good documentation available on MSDN that describes various command line switches that are supported by the Visual Studio 2005 IDE (devenv.exe).  Many of these switches have existed in previous versions of Visual Studio.

However, I wanted to draw your attention to a new switch that was added in Visual Studio 2005 - the /log switch.  This switch allows you to run Visual Studio and cause it to generate a log file of the various activities that it does behind the scenes.  This switch can be useful in debugging problems where the IDE crashes when you try to launch it, when you encounter package load failure error messages, or when you see various other errors while using various Visual Studio features.

The syntax for using this switch is the following:

devenv.exe /log <full path to log file>

The documentation currently states that the log file path is required and that it must exist before running this command line, but I have found this is not true in my experience.  I have seen this log created if it does not exist.  Also, if you do not pass in a path, Visual Studio 2005 will use the file named %USERPROFILE%\Application Data\Microsoft\VisualStudio\8.0\activitylog.xml by default.

You can find devenv.exe in the C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\ folder (if you do a default installation of Visual Studio 2005 and your OS is on the C drive - you'll have to adjust the path as appropriate on your system).

Also note, the file devenv.exe is the name of the IDE executable on the main Visual Studio editions (Professional, Team System, etc).  For the Express Editions, each IDE executable has a different name:

• Visual Basic 2005 Express Edition - vbexpress.exe
• Visual C# 2005 Express Edition - vcsexpress.exe
• Visual C++ 2005 Express Edition - vcexpress.exe
• Visual J# 2005 Express Edition - vjsexpress.exe
• Visual Web Developer 2005 Express Edition - vwdexpress.exe

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.

I have been working with a customer who ran into error code 23 while trying to download Media Center guide information after installing Update Rollup 2 for Media Center 2005.  Using the steps listed in this previous blog post, we tried to repair the BITS service using the bitsadmin.exe tool that is part of the Windows XP SP2 support tools package.  Running that tool gave an error like the following:

Failed to instantiate BITS Manager interface... - 0x80080005
Server execution failed

After talking to the BITS team, I had the customer try the following workaround and it solved the issue on this machine:

1. Check to see if the registry sub-key named HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup exists on the system
2. If not, click on the Start menu, choose Run and type cmd
3. Run the command reg add HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup /f in the cmd prompt window
4. After adding this registry value, try to start the BITS service by running net start bits

I am not sure how that registry value got deleted on this machine, but adding it back allowed Media Center guide download and other BITS-related download functionality such as Windows Update to start working again.