locked
Vista x64 and 32-bit DLL used from within XBAP RRS feed

  • Question

  • Hi,

    We have an XBAP which, at one point, loads an MC++ DLL which contains authentication logic. We have some problems clients running 64-bit operating systems.

    When opened from Windows Server 2003 x64 with Internet Explorer running in 32-bit mode, the application runs fine, inside a 32-bit PresentationHost.exe process.

    On Vista x64 however, the PresentationHost.exe process which is spawned is always a 64-bit process, even with iexplore.exe running in 32-bit mode. Our application launches, but fails as soon as it needs to access the MC++ DLL. The exception is "System.BadImageFormatEception:  is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)"

    As far as I found, no options are available to change the bitness of an XBAP application. Is there any way around this? Is there any way to force the application to be hosted inside a 32-bit application?

    Thanks,
    Wouter
    Tuesday, April 14, 2009 2:13 PM

Answers

  • What version of the framework do you run on? Originally we had the design you describe: Always run 64-bit on 64-bit Windows Vista and always run 32-bit on pre-Vista OSes--due to lacking 64-bit video and DRM support on these OSes.  But in .NET v3.5 SP1 this got accidentally broken, and now PresentationHost.exe should run with the bitness of the browser. Since 32-bit IE is default, you should be generally okay.

    But if you really need your XBAP to run in a 64-bit process, you'll need runtime logic to bind to the right bitness of MFC. Alternately, you could have two separate builds of the XBAP and serve the appropriate one based on the user-agent string from the browser.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, April 16, 2009 8:04 AM
  • Yes, the bitness design has a complex history, but we do have a simple design going forward: match the bitness of the browser.  Unfortunately we shipped Win7 with a bug in our setup package, which breaks this design.  We have published a KB article describing how it can be fixed by end users here: http://support.microsoft.com/kb/974396

    Sorry for the inconvenience.  We will fix this as soon as we can.


    Please do not send e-mail directly to this alias. This alias is for newsgroup purposes only.
    • Marked as answer by Wouter Demuynck Wednesday, September 23, 2009 5:58 AM
    Tuesday, September 22, 2009 7:07 PM

All replies

  • Haven't got a 64 bit box here to try but I could change the platform settings (use the configuration manager in the build menu) from anycpu to x86 just fine. That should do the trick for you as well.
    Tuesday, April 14, 2009 3:05 PM
  • Haven't got a 64 bit box here to try but I could change the platform settings (use the configuration manager in the build menu) from anycpu to x86 just fine. That should do the trick for you as well.
    The option is there, but changes are not allowed for XBAP applications. When changing it to x86, compilation simply fails:

    c:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.WinFX.targets(618,7): error : Cannot build a platform-specific XAML Browser Application. If HostInBrowser property is set to 'True', either do not set the PlatformTarget property or set it to 'AnyCpu'.

    (I did this from a new blanco test application. The error is not related to the rest of my code)
    Wednesday, April 15, 2009 6:09 AM
  • Guess you're prettymuch out of luck, can you recompile the dll thats giving you grief for 64 bit?
    Wednesday, April 15, 2009 6:23 AM
  • What version of the framework do you run on? Originally we had the design you describe: Always run 64-bit on 64-bit Windows Vista and always run 32-bit on pre-Vista OSes--due to lacking 64-bit video and DRM support on these OSes.  But in .NET v3.5 SP1 this got accidentally broken, and now PresentationHost.exe should run with the bitness of the browser. Since 32-bit IE is default, you should be generally okay.

    But if you really need your XBAP to run in a 64-bit process, you'll need runtime logic to bind to the right bitness of MFC. Alternately, you could have two separate builds of the XBAP and serve the appropriate one based on the user-agent string from the browser.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, April 16, 2009 8:04 AM
  • What version of the framework do you run on? Originally we had the design you describe: Always run 64-bit on 64-bit Windows Vista and always run 32-bit on pre-Vista OSes--due to lacking 64-bit video and DRM support on these OSes.  But in .NET v3.5 SP1 this got accidentally broken, and now PresentationHost.exe should run with the bitness of the browser. Since 32-bit IE is default, you should be generally okay.
    Thanks Chango, you were right: 3.5 SP1 was not installed on the machine (it was a new machine with fresh Vista install). After installing SP1, the application starts in a 32-bit PresentationHost process, and runs correctly.

    While my problem is solved, I'm still interested in some quick answers to the following questions:

    - Is this behavior expected to change again in future versions? (you mention 'accidentally broken')
    - Can you give a hint about the "runtime logic to bind to the right bitness of MFC" you mention?

    Thanks,
    Wouter
    Thursday, April 16, 2009 11:33 AM
  • No final decision yet, but it's more likely we'll keep the new bitness design, not to cause more disturbance. Seems more flexible since the user is in control.

    If you want your XBAP to be able to run in either bitness process, you have to detect in which case you are (the common way is to test the size of IntPtr) and load the appropriate DLL based on the result. So, you'd have two builds of each of your native DLLs: one for each processor architecture. If you want to avoid downloading both (while only one is ever going to be used), you have some options:
      - Put them in separate Download Groups and use the ClickOnce on-demand download API: http://msdn.microsoft.com/en-us/library/ak58kz04(VS.80).aspx.
      - Have two separate builds of the whole XBAP, detect the processor architecture reported by the browser to the server, and server the appropriate build of the application.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, April 17, 2009 7:12 AM
  • Thanks Chango, That's some interesting information.
    Friday, April 17, 2009 8:55 AM
  • Sorry to keep bothering you, but I gave the same application a try on the current Windows 7 beta, with .NET 3.5 SP1 installed (It says "3.5.1" in Add/Remove Windows Features and "1" in "HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.5\SP")

    Unfortunately for me, in this version the 32-bit iexplore.exe process DID launch a 64-bit PresentationHost.exe process.

    Just so you know.
    Friday, April 17, 2009 1:23 PM
  • This should be "normalized" in the final release of Windows 7.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, April 17, 2009 5:15 PM
  • This should be "normalized" in the final release of Windows 7.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    In the Windows 7 RC x64 version, a 32-bit Internet Explorer process still starts a 64-bit PresentationHost process.

    Just checking to know if this will still change between RC and RTM versions, or if the behavior in Windows 7 RC is final?

    Thanks
    Tuesday, May 5, 2009 11:42 AM
  • Just to be complete: the behavior is still there in Windows 7 RTM x64: a 32-bit Internet Explorer process still starts a 64-bit PresentationHost process...
    Tuesday, September 22, 2009 7:28 AM
  • Yes, the bitness design has a complex history, but we do have a simple design going forward: match the bitness of the browser.  Unfortunately we shipped Win7 with a bug in our setup package, which breaks this design.  We have published a KB article describing how it can be fixed by end users here: http://support.microsoft.com/kb/974396

    Sorry for the inconvenience.  We will fix this as soon as we can.


    Please do not send e-mail directly to this alias. This alias is for newsgroup purposes only.
    • Marked as answer by Wouter Demuynck Wednesday, September 23, 2009 5:58 AM
    Tuesday, September 22, 2009 7:07 PM