Jump to content
  • Advertisement
Sign in to follow this  
schupf

Running MDX9 Application under Vista 64Bit

This topic is 3724 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, about 1 year ago I have written a Managed DirectX 9 application. Today I tried to start this application on my new PC (64Bit Vista Business), but every time I start the debug exe the program crashes (I just get a error window which says something about "embm.exe doesnt work. windows can search online for solutions") If I open the solution file of the project in visual studio 2005 and start the program I get this error message: System.BadImageFormatException: is not a valid Win32 application. (Exception from HRESULT: 0x800700C1) But the strange thing is: I even get this exception if I set a breakpoint on the FIRST line in the Main method! How can this be possible? I thought the exception is telling me that the application cant load an image or something like that but then the app should crash if it tries to load that file and not on the first line in main! Or are the 64Bit of Vista a problem? What can I do to make the application run? How can I see where the appliaction is thrown?

Share this post


Link to post
Share on other sites
Advertisement
It definitely sounds like a 64 bit problem. That exception doesn't sound like a bitmap isn't being loaded correctly, it sounds like the "application image" (ie. the executable image) isn't being loaded correctly.

Unfortunately, Microsoft is no longer updating MDX, and has officially declared it as deprecated. I'm not sure if MDX can be made to work on x64, but if not, there is no support in the future for it.

Some of us here at GameDev have started working on a project called SlimDX, which is a replacement library for MDX. You should check it out and see if it will work for you. We have a new binary release coming out within a few days, possibly even tomorrow, so I would recommend you wait for it or grab the current source from the repository, since the version that is up for download is very old.

Although we aren't sure that SlimDX will work correctly on x64 (none of us have a 64 bit machine), if you have any troubles with it, let us know and we will be sure to quickly fix the problem.

Share this post


Link to post
Share on other sites
I assume you are building your project using the "Any CPU" platform in Visual Studio? If so, this will cause your application to load into the 32-bit CLR on a 32-bit machine, and the 64-bit CLR on a 64-bit machine.

On a 64-bit machine you will thus get a 64-bit process, into which the 32-bit MDX DLL cannot be loaded - causing your "bad image format" exception.

You need to mark your project as "x86", to force it to load into the 32-bit CLR even on a 64-bit machine.

Share this post


Link to post
Share on other sites
Bakery is correct. You cannot mix 32bit and 64bit. And since Microsoft isn't supporting MDX anymore, don't hold your breath on getting your MDX apps running as 64bit processes.

As Mike suggested, you can try SlimDX. I compile the subversion code for SlimDX as a 64 bit target and have had no problems* getting my apps to run as 64 bit processes.

At any rate, my advice is to ditch Managed DirectX.

* - admittedly, there are some areas I don't touch in SlimDX as my project has no need things like xfile support (although I see no reason why it wouldn't work) and so on - but stuff like rendering, render states, shaders, and so on checks out

Share this post


Link to post
Share on other sites
Quote:
Original post by bakery2k1
I assume you are building your project using the "Any CPU" platform in Visual Studio? If so, this will cause your application to load into the 32-bit CLR on a 32-bit machine, and the 64-bit CLR on a 64-bit machine.

On a 64-bit machine you will thus get a 64-bit process, into which the 32-bit MDX DLL cannot be loaded - causing your "bad image format" exception.

You need to mark your project as "x86", to force it to load into the 32-bit CLR even on a 64-bit machine.

Yup I had the same problem when I first started using Vista 64. I figured it out by making sure to select x86 instead of "any cpu".
XNA has the same problem and this post describes why:

Why does this occur?

64 bit Windows can run both 32 and 64 bit programs. Running a 32 bit program on a 64 bit operating system might sound slow, but actually isn't, because this uses a special CPU mode as opposed to slow emulation.

You can't mix and match, though. A 32 bit program can only load 32 bit libraries, and likewise 64 bit programs can only load 64 bit libs.

In .NET, you have three options:

* If you choose 'x86' as your target platform, the compiler produces a 32 bit program
* If you choose 'x64', you get a 64 bit program
* If you choose 'Any CPU' (the default), you get a program that can work in either mode. If you run it on 32 bit Windows, the jitter produces 32 bit code, but if you run on 64 bit Windows, it jits into 64 bit instructions. Nice!

But here's the thing: the XNA Framework is a 32 bit (x86) assembly. We do not provide a 64 bit version.

If you make an XNA Framework game using the 'Any CPU' configuration, then run this on 64 bit Windows, look what happens:

* The CLR creates a 64 bit process
* The jitter compiles your 'Any CPU' bytecode into 64 bit machine code
* Your game references the XNA Framework assembly
* The CLR looks for a 64 bit version of the XNA Framework, but cannot find one
* It tries to load the 32 bit version, but cannot load a 32 bit assembly into a 64 bit process
* This produces a confusing and poorly worded exception message :-)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!