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

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.

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.

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.

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)

Guess you're prettymuch out of luck, can you recompile the dll thats giving you grief for 64 bit?

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.

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

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.

Thanks Chango, That's some interesting information.

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.

This should be "normalized" in the final release of Windows 7.

---

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

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

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...

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.