0
0

When i try to get a System Object with the Factory class i get the following error:
BadImageFormat Exception An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)The exception occurs in the following line in fmod.cs file:
result = FMOD_System_Create(ref systemraw);

None of the examples work, there is always this exception.

So, does fmod not work with VS 2005?

  • You must to post comments
0
0

Aha! I ran into the same problem, and figured out the solution.
The error occurs when you attempt to run an x64 executable (i.e. our C# code on Win64) using an 32 bit dll (i.e. the dll packaged with the 32 bit version of fmod!) Since there are no C# wrappers bundled with the x64 version of FMOD Ex, it should be very easy to run into this problem if you’re on an x64 system.

Here is the solution:

Step 1: Download both the x64 and 32 bit versions of FMOD Ex. They must be the same version build.

Step 2: Use the C# wrappers from the 32 bit version and the x64 version of the DLL.

Step 3: Change this line of code in fmod.cs
from:
[code:1ohrjaef][line:20] public const string dll = "fmodex";[/code:1ohrjaef]
to:
[code:1ohrjaef][line:20] public const string dll = "fmodex64";[/code:1ohrjaef]

Run.

Here is a reference to how this error occurs, http://blogs.msdn.com/joshwil/archive/2 … 06567.aspx

  • You must to post comments
0
0

As pointed out above this happens because you are trying to load a native 32 bit DLL in a 64 bit application.

This is because by default .NET 2.0+ is compiled with a target platform of ‘any cpu’ which means that one build runs as 32 bit on 32 bit OS’s and 64 bit on 64 bit OS’s. Most of the time this is great until you run into the problem that the original poster is having trying to load a native 32 bit DLL in a application that is running in 64 bit mode.

There is 1 workaround for this and one long term solution

  1. Workaround

Set the .NET 2.0+ compiler (Does not affect .NET 1.1 apps because they are 32bit only) to X86 (32 bit) compile only and then do another build for X64

See: [url:v8yqs315]http://opensebj.blogspot.com/2007/12/64-bit-windows-with-c-express-net-and.html[/url:v8yqs315]

for more information

  1. Have 2 fmod DLLs. One 32 bit and one 64 bit. Then in the .NET wrapper you would have something like:

if (is64Bit())
dll = "fmod64.dll
else
dll = "fmod32.dll"

This solution would require a bit of work as the dll reference in the wrapper is currently a const and can not be changed easily during run time.

The second solution is better as it allows you to retain the power of the ‘any cpu’ build but it does require the developers of fmod to do some changes first.

I expect we will see more of this error as 64 bit computing comes of age.

  • You must to post comments
0
0

This thread is a few years old and the last post was over a year ago. Since then I changed the examples to target x86 which fixed the problem.

With regard to your long term solution, as you stated choosing a dll at runtime would require making the dll reference non-const. An alternative would be to compile targeting x64 or x86 instead of "Any CPU" and use the preprocessor to choose which dll to load. Here is a quick example of setting up a pre-processor define in C#:
http://stackoverflow.com/questions/1313 … irective-c

-Pete

  • You must to post comments
0
0

Thanks for the quick reply.

I knew the thread was over a year old but having recently run into this issue myself I could not find any other mention of it.

The examples I used were converted to VS 2008 EE upon launch and exhibited this error from the start which is why I thought it was still a problem. (Probably caused by the conversion defaulting to ‘any cpu’)

Would it be possible for you to put the preprocessor stuff in the fmod.cs file please? This would mean that I would not accidentally over-right any changes I did to the file when a new version comes out and would only have to remember to do 2 separate builds.

Thanks.

  • You must to post comments
0
0

[quote:1ddvw6bb]Would it be possible for you to put the preprocessor stuff in the fmod.cs file please?[/quote:1ddvw6bb]
There are two problems with putting that stuff into the wrapper we release:

1/ The preprocessor defines need to be set in the project setting by the developer using the wrapper. This means that it will cause problems for most users and put an extra requirement on them to set up their projects in this way.

2/ The wrapper ships with the win32 release so it is a bit unusual to have win64 specific code in there. It will probably crash if it attempts to load the win64 dll and the developer hasn’t downloaded the win64 release and put the dll beside the win32 version.

We have come up with the following solution:

We will check for a preprocessor define for win64 only. That way the win32 version will be unchanged. It will load fmodex64.dll if and only if the user has defined that preprocessor.

Let me know if that suits your needs, if so I will add it to the next development release.

I might also add a (IntPtr.size == 4) check to the standard code path to make sure it’s 32-bit.

-Pete

  • You must to post comments
0
0

[quote="peter":11w1mic9]We have come up with the following solution:

We will check for a preprocessor define for win64 only. That way the win32 version will be unchanged. It will load fmodex64.dll if and only if the user has defined that preprocessor.

Let me know if that suits your needs, if so I will add it to the next development release.[/quote:11w1mic9]

That’s more than satisfactory Pete. Thank you.

As you rightly pointed out this will leave the win32 stuff unaffected and provide an easy solution to loading the 64bit DLL in 64bit builds without custom code being entered into the fmod wrapper.

Thanks again.

  • You must to post comments
0
0

That change is in for our next release which should be next week. I also added a run time check which makes System_Create and EventSystem_Create return ERR_FILE_BAD when targeting x64 without WIN64 defined. I tried to make it give a meaningful message or exception but C# doesn’t seem to be able to throw exceptions or make message boxes from form_load in 64-bit.

-Pete

  • You must to post comments
Showing 7 results
Your Answer

Please first to submit.