Design considerations for Windows Media Center applications on 64-bit operating systems


A little while ago, I wrote this blog post describing some changes that were made to the Q podcast and video blog client sample application that is included in the Windows Media Center SDK for Windows Vista.  Those changes were made to better support running the Q application on Windows Media Center extender devices.

While we were working on this change, we ran into an interesting issue that affects 64-bit systems that I want to describe in more detail.  The specific issue involves how applications are hosted within Windows Media Center.  On 64-bit systems, applications are hosted by the 64-bit version of the ehExtHost.exe hosting process.  As a result, applications that attempt to access the registry using default registry API calls will be returned values from the 64-bit registry view (as opposed to the reflected 32-bit registry view).

This caused some problems for the redesigned Q application because the new code attempts to read from a registry value under HKEY_LOCAL_MACHINE\Software\Microsoft\Q, which is a location affected by registry reflection on 64-bit operating systems.  However, the Q application's assembly is a processor-neutral (MSIL) assembly, and as a result, we wanted to create a single installer that would work for both 32-bit and 64-bit systems.

Our initial solution was to create a 32-bit installer that installs the MSIL assembly to the GAC and writes the HKEY_LOCAL_MACHINE registry value, and to have the code use standard registry APIs to read data from this registry location.  With that version of the code and the installer, the registry value was written to the 32-bit registry (because it is a 32-bit MSI), but the Q application never found the registry value (because standard registry APIs attempt to read from the 64-bit registry), and no RSS feeds got registered by default.

We next attempted to set the msidbComponentAttributes64bit value in the Component table for the component that installs this registry value.  This strategy created the registry value in the 64-bit registry and Q worked as expected.  However, this behavior cannot be relied upon - Windows Installer does not officially allow authoring 64-bit components in a 32-bit MSI.  Doing so will generate ICE80 validation errors, and part of the Windows Vista logo program requires that MSI packages not have ICE validation errors like this.

That left us with the following options:

  1. Create separate MSI-based installers for 32-bit and 64-bit operating systems
  2. Modify the code to use P/Invokes to turn on/off mirroring at runtime to try to find the registry value - specifically, we can use the RegOpenKeyEx API with the KEY_WOW64_32KEY flag; P/Invokes are necessary here because this flag is not supported in .NET Framework registry classes
  3. Move the registry value to a part of the registry that is not mirrored (such as HKLM\System\*)
  4. Modify the code to check in HKEY_LOCAL_MACHINE\Software\Microsoft\Q and if that is not found, fall back and look in HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Q

The first option is probably the cleanest, but was too involved for an SDK sample application so we decided not to do that at this time.  I will post a WiX-based sample in the near future for anyone who would prefer to use this option for their application.

The second option involved writing a lot of additional code, which we did not have time for before the SDK was scheduled to ship.

There is not a logical location in the registry to use for the third option, especially considering that we could not use HKEY_CURRENT_USER or else we would re-introduce the Windows Media Center extender problem we were trying to solve.

Ultimately, we chose the fourth option, and the sample code that shipped in the final release of the Windows Media Center SDK for Windows Vista includes logic to look in the 64-bit registry and if the value that points to the OPML file is not found, it then looks in the 32-bit registry.  If the registry value is not found in either location, then Q skips populating RSS feeds altogether.

The important overall point of this blog post is that if you are writing a Windows Media Center application that needs to access the registry, you will need to take special care in how you design your application and your installer in order to ensure that it works equally well on 32-bit and 64-bit versions of Windows Media Center on Windows Vista Home Premium and Ultimate editions.

Comments (4)

  1. Dean Harding says:

    Wouldn’t it have been better to just modify the installer to pass KEY_WOW64_64KEY in a custom build step to add the 64-bit keys? That way, you don’t need any special code in the actual application to handle the difference.

    I guess its a limitation of Windows Installer that you can’t explicitly write to the 64-bit registry key from a 32-bit MSI "out-of-the-box", because that would be the ideal solution.

  2. Hi Dean – The suggestion you describe is the same thing as trying to set the msidbComponentAttributes64bit component attribute like I described above.  This is not allowed in Windows Installer and it causes ICE80 errors.  I agree this would be ideal if it were supported.

  3. mb@smartftp.com says:

    Dear Aaron ..

    You imply that the Vista Verified Logo requires no ICE80 validation errors. The newest document (Certified for Windows Vista Test Cases, Version 1.3.001, March 6, 2007)

    seems to to finally allow ICE80 errors in the TC12:

    TEST CASE 12. Verify application’s MSI installer does not receive any errors from the Internal Consistency Evaluators. (Req:2.1)

    (IF APPLICATION DOES NOT USE WINDOWS INSTALLER FAIL THIS TEST CASE. LOG N/A IF APPLICATION IS CLICKONCE.)

    STEPS:

    1. Open Orca

    2. Open the application’s MSI installer package in Orca

    a. From the tools menu click on Validate

    b. Select Full MSI Validation Suite from the Evaluation File drop down menu

    c. Uncheck show “INFO” Messages check box

    d. Click Go

    e. View ICE logs

    f. Make note of all errors.

    VERIFICATION:

    1. The application’s MSI package must not receive any errors in the Internal Consistency Evaluators (ICE) 1-2, 4-7, 9-15, 17-24, 27-31, 33-36, 38, 40-57, 59, 61-63, 65, 67-71, 74-78, 81-84, 86-87, 89-94, 96-99 when validated in order to pass this test case.

    I hope this information was useful to you.

    Regards,

    -Mat

    SmartFTP

  4. Hi Mberchtold – Thank you for the clarification.  The minimum Logo requirements are the ones you list below, but I strongly recommend reviewing all ICE errors/warnings in your MSI and at least understanding why they are happening in order to make an informed decision about whether or not to fix them before you ship your product.

Skip to main content