12
votes

I am trying to run my .NET 3.5 WinForms application on a Win7 x64. The application uses NHibernate and the System.Data.OracleClient to access an Oracle database. The Oracle client is 32bit.

When starting up the app I get the following error message

Attempt to load Oracle client libraries threw BadImageFormatException. This problem will occur when running in 64 bit mode with the 32 bit Oracle client components installed.

In response to that, I targetted my build to the x86 platform:

Screenshot of the Build settings

To my surprise, the very same error message appeared when trying to execute that new build on the Win7 platform.

The NHibernate assembly is loaded at runtime by Assembly.Load("...");.

Could it be that the NHibernate DLL still runs in 64 bit mode whilst the host exe runs in 32 bit mode. That sounds strange to me. Or could it be that for whatever reason, my application runs in 64 bit mode even though it was targeted to x86?


Update:

I checked my binary using CorFlags, and it is marked 32 bit:

Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.0.30319.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v2.0.50727
CLR Header: 2.5
PE        : PE32
CorFlags  : 3
ILONLY    : 1
32BIT     : 1
Signed    : 0

I also checked it in Task Manager, and it has a *32 suffix.

I also tried and used CorFlags to add the 32bit flag to all assemblies that come with my application. It still yields the same error message.

I'm puzzled... puzzled... puzzled...

6
Have you checked via task manager wether your program is running in 32-bit or 64-bit mode when it crashes? If it has "*32" behind its process name, it is 32-bit, otherwise 64-bit (assuming 64-bit OS and system.)Lasse V. Karlsen
And what did you target to x86? Your class library? Your program? Both?Lasse V. Karlsen
@Lasse: In more detail the application consists of 3 layers, 2 DLLs and 1 EXE, whereas one DLL references NHibernate. I have targetted all of these to x86, and made sure that the EXE project uses the x86 bins of the DLL projects when compiling. The only thing I can't control is the NHibernate DLL itself.chiccodoro
Are you sure the NHibernate assemblies are Any CPU, and not 64-bit?Lasse V. Karlsen
@Lasse: Yes, since the application runs smoothly on Windows XP 32 bit. I might have to try and download the source and compile it on my own, but that makes the build and deployment process a lot more complicated, and I can hardly believe that the assembly which is loaded into the EXE process can run in a different mode than the EXE itself. However, I'm not an expert in the depths of .NET...chiccodoro

6 Answers

6
votes

32-bit processes cannot load 64-bit DLLs and vice versa (see this for details). That means that if your process successfully loaded a 64-bit DLL then it most definitely is a 64-bit process. You can verify that in Task Manager (as Lasse suggested) or via other means described here. That article also has more information on .Net on Windows x64.

3
votes

Correct, it sounds like the NHibernate assembly is built with AnyCPU as its platform target. You'll need an NHibernate assembly that is built for x86 specifically.

2
votes

You can try RunAsx86

I use this tool to start .NET applications in x86 mode, when run them from command line.

0
votes

In case it helps anybody, I was running into the same symptoms with Oracle 64 bit and Windows 7 64 bit. I left the platform target alone (did not change any project settings). Instead I simply installed oracle 32 bit and that resolved the issue. Be sure to update your environment variables (i.e. ORACLE_HOME, PATH) to point to the 32 bit version.

0
votes

I have run into similar problem before. I have a windows service using Crystal Reports, everything was fine on my 64b machine, I tuned everything - the project was built to use x86 architecture.

The problem occurred when deployed to different machine, the service was failing because the Crystal Reports engine could not load log4net.dll 1.2.10 assembly. I checked the directory - the version there was 1.2.11, my local directory contained the same version. The bindingRedirect did not work.

Then I checked GAC - CR dlls are signed and were added to GAC by installer, log4net 1.2.10 was there but the processor architecture was not x86. After adding the log4net 1.2.10 for x86 architecture it worked like a charm.

0
votes

I have got the same error in my c++ oracle application which i need to run on 64 bit machine build in 32 bit machine. the bad image error is due to intermixing of dlls of 32 bit and 64 bit so i used dependency walker to find which dlls are intermixed. In that application i found that oci.dll are of 64 bit as i have installed oracle client of 64 bit but all other dlls of 32 bit. so i installed the oracle client for 32 bit on 64 bit machine and resolved this error.