XNA Framework on 64 bit Windows

Ever seen this error message?

Could not load file or assembly 'Microsoft.Xna.Framework, Version=, Culture=neutral, PublicKeyToken=6d5c3888ef60e27d' or one of its dependencies. An attempt was made to load a program with an incorrect format.

This is right up there in the pantheon of unhelpfulness. What does "incorrect format" mean, anyway? Has my framework installation somehow been corrupted?

Nine times out of ten, what the exception really meant to say was:

Could not load 32 bit assembly 'Microsoft.Xna.Framework' into a 64 bit process. Your game project is set to 'Any CPU' platform, when it should specify 'x86'.


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 πŸ™‚


Why doesn't this happen all the time?

If you use our standard project templates, these are set up to target the 'x86' platform, not 'Any CPU'. This produces a 32 bit program, which will always run in 32 bit mode, even on 64 bit Windows.

The error only occurs if you create a project using some other template, which defaults to 'Any CPU', and then manually reference the XNA Framework. This often happens when people try to use the XNA Framework inside a WinForms application, for instance.


How do I fix it?

In your Visual Studio toolbar, there should be a combo box saying 'Any CPU'.

If you are using C# Express, this toolbar entry may be grayed out. To enable it, go to 'Tools / Options', check 'Show all settings', select the 'Projects and Solutions' tab, and check the 'Show advanced build configurations' box.

Pull down the 'Any CPU' toolbar combo, and choose 'Configuration Manager'. Open the 'Active solution platform' combo, choose '<New...>', and create an 'x86' configuration.

Comments (15)

  1. lemmy101 says:

    Amazing. How come _every time_ I have a problem on XNA, and and I hunt around the net looking for answers, do I always end up finding them on your blog, or or in your posts on xna.com? πŸ˜‰

    Thanks again!


  2. Denis Bakharev says:

    Thank you!!!

    I spend two days on this problem and finally fix it!

  3. Joris Aerts says:

    So I got a whole bunch of dll’s (assemblies) which are all compiled in Any CPU mode, and one of them loads the Xna Framework. Because of the Xna-bug I had to change my .exe to x86. I rather want to change it to Any CPU mode, because the rest of my logic will run much faster on 64bit.

    Also, I don’t want to be Xna/DirectX-dependent, so I’m programming it all on an interface for which I will provide an OpenGL alternative later on. Converting my application to Mac or Linux will then be easier too. So I don’t want to inherit from the Game class, but instead from a self defined Game Interface.

    So, isn’t there any way to just isolate the Xna Framework into an x86 environment, and have my 64bit environment access it?

  4. Daniel Klein says:

    So just to be very clear on this: this problem shouldn’t occur in 32bit WinXP, no matter what CPU it’s running on, right? Even though I have an Athlon64, as long as I’m running a 32bit OS the CPU is treated like a 32bit CPU, right?

  5. ShawnHargreaves says:

    > as long as I’m running a 32bit OS the CPU is treated like a 32bit CPU, right?


  6. Creyke says:

    Great info Shawn, my artist was running 64bit and our editor wasn’t loading. All sorted, thanks.

  7. Willem Mahy says:

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

    Well… No offense… But… Thats a rather obuse statement!  Taken into account the fact that all naw PC’s nowadays are 64bit capable, should’nt  it be time by now to also supply a 64 bit version of XNA?  This would come in very handy , for example , when developing a volume rendering/ segmentation program wit a  512*512*(+/-400)*16bpp volume target!  Do you have any idea when (if ever)  we can expect a 64 bit version of the xna framework?

  8. TomaSmann says:

    My god, I spent half my day debugging this little trick. Gotta *love* those precise error messages. Man, you saved my sanity.

  9. Jesper says:

    I just wanted to say thanks for this solution. Helped me a lot.

  10. brent says:

    It didn’t solve it for me…I still have the Bad Image Format error on x86 mode…I’m compiling on a 64-bit computer.


  11. diehortusxana says:

    Thank you for this post – was really helpful!

    I did made a solution on Vista_x86 – it could compile and run on my Win7_x64 (with AnyCPU option), but when made a new simmilar project within my VS2008 I had to select really the x86 for the main WinForms project, to make it work.

    Now it is good πŸ™‚


  12. Stefan says:

    Here is the feature request for XNA x64 support:


    Feel free to vote for it πŸ™‚

  13. After reading your note, I still confused about why Surface2.0(64bit) can leverage the XNA4.0(32bit module or API) on Win7… Could you give an explanation?

  14. ShawnHargreaves says:

    > I still confused about why Surface2.0(64bit) can leverage the XNA4.0(32bit module or API)

    Like this article says, "64 bit Windows can run both 32 and 64 bit programs".  See en.wikipedia.org/…/WoW64 and msdn.microsoft.com/…/aa384249%28v=vs.85%29.aspx

Skip to main content