Dependancy Walker Error: Modules with different CPU types were found - analyzing 32-bit Fortran DLL

[Ed_F_]

I built a 32-bit Fortran DLL using Intel Parallel Studio XE 2013 with VS2010.  I did not go into the detailed settings for the project, just selected the defaults for a Release configuration for Win32 environment.  When I analyze the resulting DLL in Dependancy Walker, it gives me the error "Modules with different CPU types were found" and highlights several 64-bit DLL's in the depencencies.  In searching older posts, I thought I might have found a solution by starting from a command prompt titled "IA-32 Visual Studio 2010 mode", which sets the path variable to the various 32-bit locations.  I then started the development environment by typing devenv.  I then rebuilt my DLL and re-tested it with Dependency Walker, and got the same errors.  (see the attached screen-shot)

Any idea what I might be doing wrong?

[Steven_L_Intel1]

You can ignore this - Dependency Walker for some reason doesn't know to skip 32-bit DLLs in PATH when processing a 64-bit EXE or DLL the way Windows does.

[SergeyKostrov]

>>...Any idea what I might be doing wrong? My questions are: even if MS Depends displays that error does your application work? When you try to execute your application a runtime error message '...is not a valid Win32 application.' is displayed?

[Ed_F_]

I was running Dependency Walker on the development computer (with the compiler) when I got the errors described above.  I later ran it on some other computers and did not get that error.  The program runs fine on the development computer and most other computers it has been installed on, but not all.  I learned that I needed to run Dependency Walker on the problem computer and on a similar one without a compiler for comparison.  Comparing results to the development computer doesn't help.

[Steven_L_Intel1]

You're not doing anything wrong. You will see this anytime you run Dependency Walker on a 64-bit system when the executable is 32-bit and the 64-bit run-time DLLs are first in PATH. 64-bit Windows knows to skip over the "wrong platform" DLLs when doing its search, but Dependency Walker doesn't.

[SergeyKostrov]

>>...64-bit Windows knows to skip over the "wrong platform" DLLs when doing its search, but Dependency Walker doesn't. It is actually an issue with Win32 API functions LoadLibrary and LoadLibraryEx.

[Steven_L_Intel1]

Sergey, I don't agree. Dependency Walker needs to figure out for itself what the dependency tree is - LoadLibrary won't do that for you. You can call LoadLibrary on a 32-bit DLL and Windows will automatically ignore dependent 64-bit DLLs it find in PATH while looking for dependent DLLs.

[SergeyKostrov]

Thanks, Steve. >>...You can call LoadLibrary on a 32-bit DLL and Windows will automatically ignore dependent 64-bit DLLs it find >>in PATH while looking for dependent DLLs... I see what you mean.

[Bernard]

It is a good practice to always double check with the another tool.Dependency Walker should be able to resolve circular dependencies between libraries export and import sections.You can see it for example by looking at kernel32 imports beign linked against hal.dll.