A possible problem currently exists for hosted HTML applications in Windows Media Center for Windows Vista on 64-bit versions of Windows Vista.  Windows Media Center hosts applications in a 64-bit process, and that 64-bit process currently only has the ability to host other 64-bit processes and ActiveX controls.

A customer posted this item on his blog recently and sent me a question asking for more information about this scenario.

This issue primarily affects hosted HTML applications because they often host the Adobe Flash ActiveX control.  As of the time that I am writing this blog post, there is not a 64-bit version of the Flash player available.  When a hosted HTML application tries to check for the existence of the Flash player on a 64-bit OS, it will search in the 64-bit registry because Windows Media Center hosts applications in a 64-bit process.  The hosted HTML application will not find the Flash player installed, and most applications will then prompt the user to install the Flash player.  If a user uses the default Internet Explorer link in the Windows Start menu, it will launch the 32-bit version of Internet Explorer and the user will be able to use it to install the 32-bit version of Flash.  Then, when they return to Windows Media Center and launch the hosted HTML application again, it will continue to fail to locate Flash because it is looking for a 64-bit version not finding it because only a 32-bit version has been installed.

The Windows Media Center team is currently working on a feature that will allow applications to host both 32-bit and 64-bit processes and ActiveX controls on a 64-bit OS.  The team is planning to release this feature as a Windows Vista hotfix, but the timeframe for this release is not yet known.

In the meantime, there is not a workaround that will allow Windows Media Center applications that require 32-bit ActiveX controls such as the Flash player to work correctly on 64-bit versions of Windows Vista.

Please note that it is possible to use other Windows Media Center application development technologies such as Media Center Markup Language (MCML) or hosted .NET Framework 3.0 XBAPs instead of relying on hosted HTML.  There will be some up-front cost to learn the new technology and implement your application using it, but in the long run I think you will get a lot of benefit from using these more powerful Windows Media Center development options.  You can find more information about Windows Media Center development options in the Windows Media Center SDK for Windows Vista.

The final version of Visual Studio 2005 service pack 1 has been made available for download.  You can check out the following links for more information about this new release:

• MSDN page for Visual Studio 2005 SP1 - http://msdn.microsoft.com/vstudio/support/vs2005sp1/default.aspx
• Download site for Visual Studio 2005 SP1 for standard, professional and team editions - http://www.microsoft.com/downloads/details.aspx?FamilyId=BB4A75AB-E2D4-4C96-B39D-37BAF6B5B1DC
• Download site for Visual Studio 2005 SP1 for express editions - http://www.microsoft.com/downloads/details.aspx?FamilyId=7B0B0339-613A-46E6-AB4D-080D4D4A8C4E
• Download site for Team Foundation Server SP1 - http://www.microsoft.com/downloads/details.aspx?FamilyId=A9AB638C-04D2-4AEE-8AE8-9F00DD454AB8

One thing I want to point out is the continuing benefits provided by the Visual Studio and .NET Framework Product Feedback site.  Many of the fixes included in SP1 were issues reported directly to Microsoft by end users via the product feedback site.  I encourage you to continue to report issues that you find with Visual Studio 2005 and the .NET Framework 2.0 (as well as other Microsoft products), on the Product Feedback site.

Recently, I posted a set of instructions for creating an MSI-based installer for a Windows Media Center application using WiX v3.0 and Votive.  While I was working on writing those instructions, I noticed a frustrating issue that I could not consistently reproduce.  After I added the en-US culture attribute, saved and tried to build the MSI, I received 200+ errors about undefined localization strings in the WixUI dialog libraries.  Eventually, I discovered that the en-US culture attribute was not being passed on the command line to light.exe, and then I re-opened the property pages and discovered that the culture attribute had not been saved like I thought.

Eventually, I was able to get Visual Studio to think that the property pages needed to be saved again, and it persisted the en-US culture attribute to the .wixproj file.  I tried a couple of times to start from scratch and narrow down a set of steps, I could not find a consistent pattern that would cause the culture attribute to be correctly saved.

I found the following bug being tracked for this issue in the WiX SourceForge bug database -

http://sourceforge.net/tracker/index.php?func=detail&aid=1566296&group_id=105970&atid=642714

That bug lists an easier workaround that can be used if you run into this issue while trying to use the steps that I previously posted:

1. Open the .wixproj file in a text editor such as notepad
2. Find the section named <Cultures></Cultures> and add the culture string(s) you want to support for your MSI delimited by semi-colons
3. Save and close the .wixproj file
4. Build the .wixproj file again in Visual Studio

Recently, I was helping a customer investigate an issue in an MSI-based installer that they created for their Windows Media Center application for Windows Vista.  They included a custom action in their MSI that executed RegisterMceApp.exe /allusers to register their application to appear in Windows Media Center.  Because they used the /allusers switch, the installer required the ability to access to registry values under HKEY_LOCAL_MACHINE during execution of this custom action.  However, their setup failed during the RegisterMceApp.exe custom action with an access denied error.

This led me to undertake a more general investigation into how Windows Installer interacts with UAC.  Specifically, I set out to figure out in what circumstances an MSI-based setup will prompt the user for elevation, and how elevated privileges are propagated through the MSI to the custom actions that it contains.

Most of this information exists in MSDN documentation and various blog posts, but I had to put pieces together from several sources to finally form a complete picture in my mind about how things work behind the scenes.  I want to use this blog post to summarize the concepts that I learned during my research and try to consolidate some key things in one place for later reference.

Summary

In general, Windows Installer will prompt for elevation every time a user installs an MSI unless the MSI author specifically opts out.  There are a few key exceptions to this statement:

• If the MSI is run in silent mode (msiexec.exe /qn)
• If the product has already been installed and is managed by Group Policy
• If the user launched setup from a process that is already elevated (such as an elevated cmd prompt)
• If the MSI package already approved for elevation (such as via Group Policy deployment)
• If the AlwaysInstallElevated policy is set on the system

This means that if you author an MSI that contains payload that you know ahead of time will require elevation (such as installing files to Program Files or Windows, writing registry values to HKEY_LOCAL_MACHINE, etc), you do not need to author any special information into an MSI to ensure that it will prompt the user to elevate during installation/repair/uninstallation.

How to author custom actions that require administrative privileges

Many of the issues I have seen related to UAC elevation and MSI-based setups so far have involved custom action that fail due to insufficient privileges.  Even if an MSI has been elevated, custom actions must be authored with the correct execution options or the elevated privileges will not be propagated to them and they may fail.

Specifically, a custom action must be authored for deferred execution (using the msidbCustomActionTypeInScript attribute) and must not impersonate the user that launched setup (using the msidbCustomActionTypeNoImpersonate attribute).

In WiX syntax, this means that a custom action must contain the attributes that I have bolded in the following example:

<CustomAction Id="MyCustomAction" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="check" Impersonate="no"/>

-or-

<CustomAction Id="MyCustomAction" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="commit" Return="check" Impersonate="no"/>

Most of the cases I have seen where Windows Media Center application developers have tried to run RegisterMceApp.exe /allusers from a custom action but seen it fail with an access denied error have been caused by not properly setting the msidbCustomActionTypeNoImpersonate bit.  In WiX syntax, if you do not specify the Execute attribute, it will default to immediate, which means that the custom action will run with the privileges of the user who ran the setup.

If you are using a Visual Studio 2005 setup/deployment project to create an MSI, there is not a way to set the msidbCustomActionTypeNoImpersonate bit in the designer UI.  Instead, you will need to use a custom post-build step like the one I previously described in this blog post to modify the MSI after the build has completed.

I also want to point out that marking a custom action to not impersonate and to run deferred is necessary if the custom action requires elevated privileges in any scenario, regardless of whether or not the MSI is installed on Windows Vista.  For example, if you plan to support Group Policy deployment of your MSI on Windows 2000, XP or 2003 with elevated privileges, the custom action needs to be marked with these same flags.  This is not a new requirement in Windows Vista.

How to opt out for an MSI that does not require elevation

As a setup developer, it is possible to create an MSI that will not prompt the user for elevation, but it requires some extra steps.  You will need to do the following:

• Ensure that no actions performed in your MSI require elevation.  This means that all files and registry must be created in a per-user location and no custom actions require administrator privileges
• Set the ALLUSERS property to an empty string
• Set bit 3 of the Word Count summary property to 8 to indicate that elevated privileges are not required

In addition, Windows Vista includes some logic to automatically prompt for elevation for executables that it believes to be setup EXEs.  Therefore, if your setup contains a wrapper setup EXE that launches the MSI (as opposed to just an MSI that the user invokes directly), you will need to create and embed a manifest file to prevent Windows Vista from automatically prompting the user for elevation if you have designed a fully per-user setup.  You will want to create an application manifest for your setup EXE and and specify the requested execution level of "asInvoker" for your setup process.

For more information, see the section titled Create and Embed an Application Manifest with your Application in the Windows Vista application development requirements for UAC compatibility white paper.

Informing the user of an impending elevation request

Windows Installer 4.0 added a new UI attribute that can be used to add the UAC elevation shield icon to a button in native MSI setup UI.  To display this shield, add the ElevationShield attribute to the push button control for the Install Now button in your MSI UI.

Windows Installer will automatically show the shield as part of the button control if it detects that the MSI is running with normal user privileges, and will not show the shield if it detects that the MSI is running with elevated privileges.

A note about logging

In Windows Installer 4.0 on Windows Vista, it is possible to identify what decisions are made regarding UAC elevation during an MSI setup session.  To do this, you can search for the prefix MSI_LUA in the Windows Installer verbose log file.

Additional reference information

The following MSDN articles are helpful in understanding how Windows Installer interacts with UAC on Windows Vista:

• Using Windows Installer with UAC - http://msdn.microsoft.com/library/aa372468.aspx
• Guidelines for MSI packages in UAC scenarios - http://msdn.microsoft.com/library/aa368772.aspx
• Installing a package with elevated privileges for a non-administrator - http://msdn.microsoft.com/library/aa369519.aspx
• Authoring MSI packages that will not display a UAC prompt - http://msdn.microsoft.com/library/aa367800.aspx
• Information about the Word Count summary property in an MSI - http://msdn.microsoft.com/library/aa372870.aspx
• Information about custom action in-script execution options - http://msdn.microsoft.com/library/aa368069.aspx
• Using the ElevationShield attribute in MSI UI - http://msdn.microsoft.com/library/aa368344.aspx

Robert Flaming's blog also contains an in-depth series of articles with information about how Windows Installer interacts with UAC.  You can take a look at this blog post as a starting point.  It contains a table of contents with links to his entire series of posts.

I want to specifically thank Carolyn, the development lead for the Windows Installer, for her patience as I asked several stupid questions to try to better understand these scenarios.

<update date="12/14/2006"> Clarified the comments in the custom action section about execution options.  A custom action can be marked as deferred or commit and still allow for elevation to be propagated to it.  The key point is that the custom action must include the msidbCustomActionTypeInScript and msidbCustomActionTypeNoImpersonate attributes. </update>

<update date="4/30/2008"> Fixed broken links in the text of this post. </update>

Niall Ginsbourg from Mobilewares is working on another Windows Media Center application for Windows Vista using Media Center Markup Language (MCML) - Big Screen TV Series.

The Big Screen TV Series application monitors your recorded TV shows and scheduled recordings for the future and downloads comprehensive series information (episode summaries, images, cast information, etc).  Then it presents this information in a nice UI that you can use to browse, view and manage your TV shows within Windows Media Center.  In addition, the management and configuration tools for the application are also written in MCML and are available within Windows Media Center (instead of via a separate tool that would have to be run from the standard Windows desktop).

Big Screen TV Series is currently still under development, but you can find more information in these 2 blog posts on the Big Screen Blog:

• Big Screen TV Series blog post part 1 - http://mobilewares.spaces.live.com/blog/cns!78533A1A2E078194!177.entry 
• Big Screen TV Series blog post part 2 - http://mobilewares.spaces.live.com/blog/cns!78533A1A2E078194!183.entry

Both posts include some screenshots of the application in action.  In particular, I'm impressed with the mirror effects for the show "cover art" and the gallery view that Niall has created to browse series information.

Also, this application illustrates two powerful concepts that I wanted to emphasize here:

1. Developers can use the Windows Media Center SDK to create new Windows Media Center experiences that expand on and exceed functionality provided by the built-in Windows Media Center experiences.  In this case, instead of being stuck with the TV gallery that is provided by default in Windows Media Center, Niall decided to create more in-depth views into TV episode and series information to make a more enjoyable TV browsing experience.
2. Like with any programming language, designing good building blocks (controls, base classes, etc) is a key to enabling future productivity.  In MCML, it is possible to define a rich set of common controls and then use them in multiple applications.  Spending the time up-front to create these controls makes creating each subsequent application much faster and easier.  I think Niall is demonstrating this nicely with the rate at which he is cranking out MCML-based Windows Media Center applications for Windows Vista.

I previously posted an example of how to use WiX to build an MSI-based installer for a Windows Media Center application.  In that example, I created an installer for the Q podcast and video blog client sample application that is included in the Windows Media Center SDK for Windows Vista, and I used WiX v2.0.

Since then, I have been asked by a few customers about how to create an equivalent installer using WiX v3.0.  I decided to try converting the sample installer files for the Q sample application that are installed by the Windows Media Center SDK to WiX v3.0 format to determine what work would be required.  There are several changes required to get everything working correctly in WiX v3.0, so I am going to post an updated set of setup files, scripts and instructions to demonstrate how to create an MSI-based installer for a Windows Media Center application using WiX v3.0.

One of the biggest additions in WiX v3.0 is MSBuild integration for the Votive Visual Studio add-in for WiX.  This means you can create a Visual Studio project (named a .wixproj), add it to the solution with the Q sample application, and directly build an MSI for your applications after building the binary files that make up your application.  You can also use MSBuild command lines to build your binaries and MSI directly without using the Visual Studio UI.

Votive (like all Visual Studio add-ins) is only supported on Visual Studio 2005 standard edition and higher, so I am going to post 2 separate sets of instructions - one that is similar to the instructions in the Windows Media Center SDK and uses a batch file to build the MSI using WiX tools (so that you can build an MSI using Visual C# 2005 Express Edition if desired); and the other that uses Votive to create a .wixproj and build the MSI using MSBuild within the Visual Studio IDE.

Building an MSI for Q by calling WiX tools directly

The following steps can be used to build an MSI for the Q sample application from Visual C# 2005 Express Edition or Visual Studio 2005 by adding a post-build step that executes a batch file that will call the WiX compiler (candle.exe) and linker (light.exe):

1. Install Windows Vista Home Premium or Ultimate Edition
2. Install Visual C# 2005 Express Edition or Visual Studio 2005 standard or higher
3. Install the Windows Media Center SDK for Windows Vista
4. Install the latest version of WiX 3.0 from http://sourceforge.net/project/showfiles.php?group_id=105970&package_id=168888. You need to install the ProjectAggregator2 MSI and then the WiX 3.0 MSI
5. Download this zip file with updated Q setup files and extract the contents to the Q project directory. The Q project will be installed to %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Q if you installed the Windows Media Center SDK to the default location
6. Right-click on the shortcut for Visual Studio 2005 or Visual C# 2005 Express Edition, choose Run as administrator and click Continue to launch Visual Studio with elevated privileges
7. Open Q.sln - it will be installed to %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Q if you installed the Windows Media Center SDK to the default location
8. Right-click on the Q project in the Solution Explorer and choose Properties
9. Select the Build Events tab
10. Add a new entry to the Post-build event command line text box that says "$(ProjectDir)\SetupWiXv3\build_q.bat" $(ConfigurationName)
11. Click on the File menu and choose Save All
12. Click on the Build menu and choose Rebuild Solution to build the Q binaries and then run build_q.bat

The above steps will produce an MSI named Q_Podcast_Client.msi in %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Q\bin\release (or \bin\debug\ for the Debug version of the Q application).

Building an MSI for Q using Votive

The following steps can be used to build an MSI for the Q sample application directly from Visual Studio 2005 using the Votive WiX add-in:

1. Install Windows Vista Home Premium or Ultimate Edition
2. Install Visual Studio 2005 standard or higher
3. Install the Windows Media Center SDK for Windows Vista
4. Install the latest version of WiX 3.0 from http://sourceforge.net/project/showfiles.php?group_id=105970&package_id=168888. You need to install the ProjectAggregator2 MSI and then the WiX 3.0 MSI
5. Download this zip file with updated Q setup files and extract the contents to the Q project directory. The Q project will be installed to %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Q if you installed the Windows Media Center SDK to the default location
6. Right-click on the shortcut for Visual Studio 2005, choose Run as administrator and click Continue to launch Visual Studio with elevated privileges
7. Open QWiXv3.sln - it will be installed to %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Q if you installed the Windows Media Center SDK to the default location
8. In the Visual Studio Build menu, choose Batch Build...
9. Select the configurations you want to build and click the Rebuild button to build them

The above steps will produce an MSI named Q_Podcast_Client.msi in %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Q\QWiXv3\bin\release (or \bin\debug\ for the Debug version of the Q application).

How to add a .wixproj to an existing Windows Media Center application solution

If you would like to add a .wixproj to your own Visual Studio 2005 solution, you can use steps similar to the following.  These are the steps I used to create the project files used in the steps above:

1. Install Windows Vista Home Premium or Ultimate Edition
2. Install Visual Studio 2005 standard edition or higher
3. Install the Windows Media Center SDK for Windows Vista
4. Install the latest version of WiX 3.0 from http://sourceforge.net/project/showfiles.php?group_id=105970&package_id=168888. You need to install the ProjectAggregator2 MSI and then the WiX 3.0 MSI
5. Right-click on the shortcut for Visual Studio 2005, choose Run as administrator and click Continue to launch Visual Studio with elevated privileges
6. Open Q.sln - it will be installed to %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Q if you installed the Windows Media Center SDK to the default location
7. Right-click on the Q solution and choose Add | New Project...
8. In the Add New Project dialog, click on the WiX item in the Project types list and select WiX Project in the Templates list
9. Click on the Browse button and browse to the location of the Q project so that the WiX project will be created in a sub-directory under the Q project folder. The Q project will be installed to %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Q if you installed the Windows Media Center SDK to the default location
10. Click OK to add the new WiX Project to the Q solution
11. In the new WiX Project you created, right-click on References and choose Add Reference...
12. In the Add WiX Library Reference dialog, click on the Browse tab, select the item named WixUIExtension.dll and click Add
13. Select the item named WixUtilExtension.dll and click Add
14. Click OK to dismiss the Add WiX Library Reference dialog
15. Double-click on the WiX source (WXS) file that was added to the new WiX project by default, select all of the text in the file and delete it
16. Add the contents of the updated Q WXS file from this location
17. Right-click on the WiX project and choose Add | New Item...
18. In the Add New Item dialog, select WiX Localization File and click Add to add a new localization file
19. Double-click on the WiX localization (WXL) file that was added to the project in the previous step, select all of the text in the file and delete it
20. Add the contents of the updated Q_en-us.wxl file from this location
21. Right-click on the WiX project and choose Project Dependencies...
22. In the Project Dependencies dialog, click on the Dependencies tab, select the WiX project in the Projects dropdown, and check the box for Q in the Depends on list box. This will cause the Q binaries to be rebuilt each time you rebuild the MSI
23. Right-click on the WiX project and choose Properties
24. Click on the Compiler tab
25. In the Configuration dropdown, select Debug
26. Add the string BuildType=Debug to the Define constants text box
27. In the Configuration dropdown, select Release
28. Add the string BuildType=Release to the Define constants text box
29. Click on the Linker tab
30. In the Configuration dropdown, select All Configurations
31. Add the string en-US to the Cultures text box
32. In the Visual Studio File menu, choose Save All
33. In the Visual Studio Build menu, choose Batch Build...
34. Select the configurations you want to build and click the Rebuild button to build them

The above steps will produce an MSI in %programfiles%\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Q\<your WiX project name>\bin\release (or \bin\debug\ for the Debug version of the Q application).

Changes made to Q setup to convert the setup files from WiX v2.0 to v3.0

If you are interested, the following is a summary of the changes that I made to convert the WiX setup files for the Q sample application from v2.0 format to v3.0 format:

1. Converted WixUI and WixCA to use new WiX v3.0 extensions named WixUIExtension.dll and WixUtilExtension.dll; as part of this, I added 3 WiX variables to provide customized setup UI bitmaps and a customized license agreement
2. Created a new component named QShortcut that is used to install the shortcuts to the Q application.  This new component has a HKEY_CURRENT_USER registry value as a keypath and a RemoveFolder entry.  This new component resolves ICE43, ICE57 and ICE64 errors that would otherwise occur while validating Q_Podcast_Client.msi.  Because the Q MSI sets the ALLUSERS property to 1, these 3 ICE validation failures would likely not cause any functional problems to end users, but WiX v3.0 performs ICE validation during the linking phase of the setup build process by default, and I preferred to present a sample that did not rely on suppressions for these ICE validation errors.
3. Updated some attributes whose names have changed between WiX v2.0 and v3.0 (such as Source instead of src, RegistryValue instead of Registry, Name instead of LongName because WiX v3.0 performs automatic short filename generation, etc)
4. Added culture information to the WiX localization (WXL) file, and added a command line parameter to light.exe to specify the en-US culture
5. Updated the WiX xmlns statement to use the WiX v3.0 schema instead of the WiX v2.0 schema
6. Updated source file locations to use relative paths so the build scripts no longer had to copy all of the source files to a single directory; as part of this, I added a WiX preprocessor variable named BuildType to allow the build process to dynamically pick up debug or release binaries depending on which configuration is built; this step was not technically necessary to convert the files to WiX v3.0 format, but makes the setup build process cleaner and easier to understand

<update date="1/23/2007"> Removed Visual C# Express from the list of possible Visual Studio versions in the steps for using Votive to build the Q installer.  The Visual Studio 2005 Express Editions do not support installing add-ins, so Votive (like all Visual Studio add-ins) requires Visual Studio 2005 Standard Edition or higher. </update>

I just noticed today that the documentation included in the help file that ships in the Windows Media Center SDK for Windows Vista has been published on MSDN.  This makes it easier to access the documentation by performing web searches on a system that does not have the Windows Media Center SDK installed.

You can now view the documentation included in the Windows Media Center SDK for Windows Vista online on MSDN at this location - http://msdn2.microsoft.com/en-us/library/ms818424.aspx.

A new set of MSDN Forums have been created to discuss Windows XP Embedded issues.  If you have any questions about XP Embedded development or deployment scenarios, I encourage you to check out these links:

• Windows XP Embedded forum home - http://forums.microsoft.com/embeddedwindows/default.aspx?siteid=47
• Embedded Enabling Features (EEF) forum - http://forums.microsoft.com/EmbeddedWindows/ShowForum.aspx?ForumID=1178&SiteID=47
• Components and run-time image issues forum - http://forums.microsoft.com/EmbeddedWindows/ShowForum.aspx?ForumID=1179&SiteID=47
• XP Embedded tools forum - http://forums.microsoft.com/EmbeddedWindows/ShowForum.aspx?ForumID=1180&SiteID=47
• XP Embedded miscellaneous forum - http://forums.microsoft.com/EmbeddedWindows/ShowForum.aspx?ForumID=1181&SiteID=47

A white paper has recently been published that outlines development, design and deployment guidelines for hosted HTML applications for Windows Media Center in Windows Vista.  Included in this documentation is a specific set of factors that developers must consider in Windows Vista that are new or changed from previous versions of Windows Media Center.

If you plan to migrate forward an existing hosted HTML application, I encourage you to check out this new white paper at the following location:

Development and Compatibility Considerations for HTML Applications in Windows Media Center for Windows Vista - http://msdn2.microsoft.com/en-us/library/aa992048.aspx

Also, if you are developing applications using Windows Media Center, I strongly encourage you to first check out the new Media Center Markup Language (MCML) development platform in Windows Vista before performing a simple port of any existing HTML applications or creating new HTML applications.  MCML offers many benefits over HTML for Windows Media Center applications, including access to the same UI and animation system used by Windows Media Center itself and full-fidelity rendering on Xbox 360 Media Center extenders.  You can download the Windows Media Center SDK for Windows Vista to learn more.

I have heard from a few customers in recent weeks who received an error dialog every time they launched Windows Media Center.  This dialog had the following title and text:

• Title: ehExtHost - Common Language Runtime Debugging Services
• Text: Application has generated an exception that could not be handled.

Windows Media Center was usable after dismissing this dialog, but it was really annoying to have to dismiss it each time Windows Media Center was launched.  Since I have seen this issue multiple times recently, I wanted to describe some troubleshooting steps that can be used to resolve this issue in many instances.

The ehExtHost process is a hosting process for Windows Media Center add-ins.  When it crashes, it typically means that the add-in itself has crashed inside of its process space.  Windows Media Center supports a type of add-ins known as background add-ins.  These add-ins are launched when Windows Media Center is launched and run in the background as long as the main Windows Media Center process is running on system.  When ehExtHost crashes immediately after Windows Media Center is launched, it typically means that an add-in registered in the background category has crashed.

In many cases, users may be unaware of what add-ins are installed on their systems, particularly in the case of Windows Media Center systems purchased from an OEM or system builder because the manufacturer may pre-install add-ins.  Without knowing what add-ins are installed on the system, it is a bit more difficult to determine which add-in is causing ehExtHost to crash.

In the cases I have seen, I narrowed down the issue by looking in the registry to determine which add-ins are installed in the background category.  Windows Media Center stores information about registered add-ins in the following registry sub-hives:

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility

These hives normally have 3 sub-keys:

• Applications
• Categories
• Entry Points

Add-ins that are registered in the background category will appear in a sub-key named ...\Extensibility\Categories\Background.  The structure for a specific add-in looks like the following (and it is valid for this structure to appear in HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE even though I only list HKLM below):

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Applications\{application_guid}]

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Categories\Background\{entrypoint_guid}]
AppId={application_guid}

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Entry Points\{entrypoint_guid}]

The {application_guid} value and {entrypoint_guid} values must match in the 2 places they are listed above, and together they represent a specific entry point for an add-in.

In the cases of the customers I talked to, they only had one add-in registered in the background category, and I had them rename the 3 registry sub-keys above and that caused Windows Media Center to stop trying to launch this add-in when starting up, and ehExtHost stopped crashing.

In some cases, it may be possible that multiple applications are registered in the background category.  In that case, I suggest renaming the sets of 3 registry values that correspond to each add-in one at a time to narrow down which add-in is causing the ehExtHost crash.

In general, it would be best to use official unstall mechanisms to unregister the add-in, but I have seen my share of add-ins that either do not create Add/Remove Programs entries or that do not correctly unregister themselves during uninstall.  Therefore it is sometimes necessary to directly edit the registry.  It is important to note that I always recommend renaming the registry sub-keys as opposed to deleting them because you can rename the sub-keys back in case something goes wrong.

Important note:  most cases I have seen have been caused by uninstalling a specific Symantec Norton anti-virus add-in.  I posted separate instructions in this blog post that describe how to work around this issue.  Before proceeding with the instructions in this post, I suggest taking a look at this other blog post to see if they apply on your system.

If you are unsure about what add-ins are installed and what the possible cause of this type of crash is, you can use the following command lines to gather the relevant registry information and send them to me so I can try to advise.

1. Click on the Start menu, choose Run, type cmd and click OK
2. Copy and paste the following command into the cmd prompt: start /wait regedit /e %temp%\hkcu_mce_extensibility.reg "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility"
3. Copy and paste the following command into the cmd prompt: start /wait regedit /e %temp%\hklm_mce_extensibility.reg "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Media Center\Extensibility"
4. Click on the Start menu, choose Run, type %temp% and click OK
5. Find the files named %temp%\hkcu_mce_extensibility.reg and %temp%\hklm_mce_extensibility.reg, right-click on them and choose Send To, then Compressed (zipped) Folder to add them to a zip file

<update date="9/25/2007"> Added more specific information about how to create a zip file with the registry information </update>

<update date="10/19/2007"> Added a link to a specific work around that helps solve most of the ehExtHost crashes that I have seen so far </update>

<update date="2/17/2009"> Moved the note about the Symantec uninstall issue to hopefully help people find it more easily so they know to try that workaround before they export their registry keys using the steps in this blog post. </update>

Question:

I have a production server that is running Windows Server 2003.  This OS comes with the .NET Framework 1.1 pre-installed, and it is being used as an ASP.NET web server.  I want to install the .NET Framework 2.0 to enable some additional applications, but I do not want to interfere with the ASP.NET web server that is using the .NET Framework 1.1.  How can I install the .NET Framework 2.0 but ensure that my web server continues to use the .NET Framework 1.1 when it hosts ASP.NET pages?

Answer:

It is not supported to install the .NET Framework 2.0 without installing the files for ASP.NET, and it is also not supported to skip ASP.NET registration during .NET Framework 2.0 setup on systems that have IIS installed and enabled.  However, there are a couple of options that will allow you to continue to use the .NET Framework 1.1 for web applications that are hosted on your server.

Option 1

In this option, you install the .NET Framework 2.0 and then use the .NET Framework 1.1 version of aspnet_regiis.exe to update the IIS metabase to use the .NET Framework 1.1 for web applications that it hosts.  To do this, use the following steps:

• Install the .NET Framework 2.0 using your preferred means of installation.  For example, you can use one of the command line switches in this blog post to perform a silent or unattended installation.
• After installation completes, run %windir%\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis.exe -i -enable to re-associate the .NET Framework 1.1 with IIS by default

Option 2

In this option, you install the .NET Framework 2.0 and pass in a property that causes it to use a different command line when it runs aspnet_regiis.exe during installation.  The property is named NOASPUPGRADE and it causes setup to run aspnet_regiis.exe -ir instead of aspnet_regiis.exe -iru.  The command line in this option looks like the following:

dotnetfx.exe /c:"install.exe /msipassthru MSI_PROP_BEGIN""NOASPUPGRADE=1""MSI_PROP_END"

Please note that I am not an expert in ASP.NET functionality, so I am not 100% sure what the difference is between running aspnet_regiis.exe -ir and aspnet_regiis.exe -iru.  It appears that the -ir switch will cause ASP.NET to not update any scriptmaps in IIS, whereas the -iru switch will cause ASP.NET to not update scriptmaps in IIS for existing applications only.

The -iru switch is new in the .NET Framework 2.0, and running aspnet_regiis.exe -? shows the following information for the various -i switches:

• -i  - Install this version of ASP.NET and update scriptmaps at the IIS metabase root and for all scriptmaps below the root. Existing scriptmaps of lower version are upgraded to this version.
• -ir - Install this version of ASP.NET, register only. Do not update scriptmaps in IIS.
• -iru - Install this version of ASP.NET. If there are any existing applications that uses ASP.NET, it will not update scriptmaps in IIS.

A note about .NET Framework 1.1 and ASP.NET behavior

It is also important to note that .NET Framework 2.0 setup behaves differently than .NET Framework 1.1 setup with respect to ASP.NET registration.  In the .NET Framework 1.1, the default behavior of setup is to run aspnet_regiis.exe -i, which forces upgrade of existing applications.  In the .NET Framework 2.0, if there are any existing applications, they will not be upgraded by default.

Also, an equivalent to option 2 existed for the .NET Framework 1.1, but it can be accomplished with a simpler command line switch.  The command line looks like the following for the .NET Framework 1.1:

dotnetfx.exe /c:"install.exe /noaspupgrade"

Question:

I have seen some of your previous blog posts (such as this and this) regarding compatibility issues when installing and using Visual Studio 2005 on Windows Vista.  Is there a complete list of known issues that I can review to see what other types of issues might be encountered?

Answer:

There is a consolidated list of known issues in the MSDN article at http://msdn2.microsoft.com/en-us/vstudio/aa948853.aspx.  This article contains the following specific sub-sections that may be useful depending on your scenario:

• Visual Studio on Windows Vista FAQ
• Issues running Visual Studio 2005 on Windows Vista with normal user permissions
• Issues running Visual Studio 2005 on Windows Vista with elevated administrator permissions
• Issues running Visual Studio .NET 2003 on Windows Vista

If you run into any issues that are not in any of the above lists, please report them using the Visual Studio bug reporting site.

Niall Ginsbourg of Mobilewares has posted an interesting entry on the Big Screen Blog that I wanted to bring to your attention if you haven't seen it yet.  He has created a couple of new features for the Big Screen family of Windows Media Center applications - an online version checker, and an online product catalog.

The online product catalog is a Media Center Presentation Layer Web Application that is hosted at http://mobilewares.net/mcml/default.aspx.  You can quickly view the product catalog by using these steps:

1. On a Windows Vista Home Premium or Ultimate system, install the Windows Media Center SDK for Windows Vista
2. Install the MCML Preview Tool Launcher power toy
3. Click on the Start menu, choose All Programs, then Microsoft Windows Media Center SDK, then MCML Preview Tool Launcher
4. In the URI text box, copy and paste the value http://mobilewares.net/mcml/default.aspx
5. Click Go to load the URI for the Mobilewares Online Showcase and view it in the MCML Preview Tool

You can view more details about these features in the blog post at http://mobilewares.spaces.live.com/Blog/cns!78533A1A2E078194!174.entry.  Niall didn't post a lot of details about how he implemented the online version checking and automatic updating scheme for these applications, so hopefully he'll talk more about how this feature works behind the scenes in a future blog post....

We ran into an issue while testing the final build before we released the Windows Media Center SDK for Windows Vista that I wanted to describe here because it affects all MSI-based setups on Windows Vista and Windows Server 2008.

In preparation for shipping, we digitally signed the MSI for the Windows Media Center SDK.  When an MSI is digitally signed and you try to install it, Windows Vista lists the publisher's information in the User Account Control (UAC) elevation prompt that appears during installation.  In the case of the Windows Media Center SDK setup, the UAC prompt includes the following information:

Windows Media Center SDK
Microsoft Corporation

However, when a user attempts to uninstall the Windows Media Center SDK, the UAC prompt includes the following somewhat scary text:

An unidentified program wants to access your computer

Don't run the program unless you know where it's from or you've used it before.

Unidentified publisher

After some further investigation and discussions with the Windows Installer team, we determined that this behavior happens for all MSI-based setup packages on Windows Vista and Windows Server 2008 during uninstall.  This issue was also previously mentioned on the Windows Vista compatibility team blog.

The reason that this happens is that when installing an MSI, Windows Installer caches a copy of the MSI in the %windir%\Installer folder that is used during uninstall.  The cached MSI is different than the original MSI because Windows Installer removes unnecessary information in order to save disk space.  Once the original MSI is changed, the digital signature is invalidated.  UAC for Windows Vista and Windows Server 2008 always shows a prompt stating that an unidentified program wants to access your computer when you try to install or uninstall an MSI that does not have a valid digital signature.  For more information about how digital signatures work in Windows Installer, check out this blog post by Heath Stewart.

There is not currently anything you can do to avoid this unidentified publisher message when uninstalling an MSI on Windows Vista or Windows Server 2008.  The Windows Installer team is preparing to publish a knowledge base article describing this scenario, but I wanted to let folks know in the meantime in case you run into this issue and attempt to try to resolve it.

<update date="12/4/2006"> Added a link to a blog post written by Heath Stewart about digital signatures in Windows Installer. </update>

<update date="6/15/2008"> Added information to indicate that this issue affects Windows Server 2008 in addition to Windows Vista. </update>

A while back, I wrote this blog post that listed registry values that could be used to detect the presence of each individual edition of Visual Studio 2005.  Recently, I was asked for a similar list of registry values for Visual Studio .NET 2002 and 2003, so I did some research and dug up a list of registry values that can be used for this purpose.

Detecting Visual Studio .NET 2002

You can use the following registry values to detect whether or not each edition of Visual Studio .NET 2002 is installed:

• Visual Studio .NET 2002 Enterprise Architect Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.0\Setup\VS\Arch\ProductDir
• Visual Studio .NET 2002 Enterprise Developer Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.0\Setup\VS\Ent\ProductDir
• Visual Studio .NET 2002 Professional Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.0\Setup\VS\Pro\ProductDir
• Visual Studio .NET 2002 Academic Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.0\Setup\VS\Acad\ProductDir
• Visual Studio .NET 2002 Trial Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.0\Setup\VS\Trial\ProductDir
• Visual Studio .NET 2002 Partner Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.0\Setup\VS\IDE\ProductDir
• Visual Basic .NET 2002 Standard Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.0\Setup\VB\Std\ProductDir
• Visual C++ .NET 2002 Standard Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.0Setup\Servicing\SKU\<product name>
• Visual C# .NET 2002 Standard Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.0\Setup\Servicing\SKU\<product name>

In the above registry values, ProductDir is a REG_SZ value that specifies a fully qualified path to the Visual Studio .NET 2002 root installation directory.  By default, this value will be set to c:\Program Files\Microsoft Visual Studio .NET, but will be different if the user has installed Visual Studio .NET 2002 to a non-default path.

The value <product name> resolves to the exact name of the product in question.  For example, Visual C++ .NET Standard - English or Visual C# .NET Standard - English.  Note that this value is language-specific, so you will need to perform a sub-string search for registry values listed above that include <product name> or search for each of the possible languages - Chinese (Simplified), Chinese (Traditional), English, French, German, Italian, Japanese, Korean or Spanish.

If you do not care which edition is installed, you can use the following registry value to detect whether or not any edition of Visual Studio .NET 2002 is installed:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.0\Setup\VS\EnvironmentPath

EnvironmentPath is a REG_SZ value that specifies a fully qualified path to the file devenv.exe.

Detecting Visual Studio .NET 2003

You can use the following registry values to detect whether or not each edition of Visual Studio .NET 2003 is installed:

• Visual Studio .NET 2003 Enterprise Architect Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Setup\VS\Arch\ProductDir
• Visual Studio .NET 2003 Enterprise Developer Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Setup\VS\Ent\ProductDir
• Visual Studio .NET 2003 Professional Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Setup\VS\Pro\ProductDir
• Visual Studio .NET 2003 Academic Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Setup\VS\Acad\ProductDir
• Visual Studio .NET 2003 Trial Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Setup\VS\Trial\ProductDir
• Visual Studio .NET 2003 Partner Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Setup\VS\IDE\ProductDir
• Visual Basic .NET 2003 Standard Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Setup\VB\Std\ProductDir
• Visual C++ .NET 2003 Standard Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Setup\Servicing\SKU\<product name>
• Visual C# .NET 2003 Standard Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Setup\Servicing\SKU\<product name>
• Visual J# .NET 2003 Standard Edition - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<product name>\UninstallString

In the above registry values, ProductDir is a REG_SZ value that specifies a fully qualified path to the Visual Studio .NET 2003 root installation directory.  By default, this value will be set to c:\Program Files\Microsoft Visual Studio .NET 2003, but will be different if the user has installed Visual Studio .NET 2003 to a non-default path.

The value <product name> resolves to the exact name of the product in question.  For example, Visual C++ .NET Standard 2003 - English, Visual C# .NET Standard 2003 - English or Visual J# .NET Standard 2003 - English.  Note that this value is language-specific, so you will need to perform a sub-string search for registry values listed above that include <product name> or search for each of the possible languages - Chinese (Simplified), Chinese (Traditional), English, French, German, Italian, Japanese, Korean or Spanish.

If you do not care which edition is installed, you can use the following registry value to detect whether or not any edition of Visual Studio .NET 2003 is installed:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VS7\7.1

7.1 is a REG_SZ value that specifies a fully qualified path to the Visual Studio .NET 2003 root installation directory.  By default, this value will be set to c:\Program Files\Microsoft Visual Studio .NET 2003, but will be different if the user has installed Visual Studio .NET 2003 to a non-default path.