none
32 bit console application on 64-bit system and Dependency Walker

    Question

  • I compile a very simple console application from the command line using the Visual Studio 2008 32-bit Command Prompt under Windows Vista 64. Their are no compiler/linker errors.

    When I bring up the exe under Dependency Walker it shows my exe correctly as a 32-bit application but with dependencies on the 64-bit kernel32.dll and the 64-bit ntdll.dll, and gives me the error that "Modules with different CPU types were found.".

    Is this an error in Dependency Walker ? Does my console application really use 64-bit Windows Vista DLLs ? Is having a 32-bit exe linked to 64-bit DLLs possible and correct ?

    I notice that when I execute my console application, there is no error and the application runs correctly. How is this possible if I am really mixing modules with different CPU types ?
    Friday, June 26, 2009 6:06 PM

Answers

  • Evidently the 32bit version of Dependency Walker correctly shows the dependencies for a 32-bit module, while the 64bit version of Dependency Walker can not do so. So the problem is solved and my 32bit console application, when viewed using the 32bit version of Dependency Walker, correctly shows that it is using the 32bit versions of kernel.dll and ntdll.dll in the syswow64 Vista system directory.

    Case solved.
    • Marked as answer by eldiener Friday, June 26, 2009 7:53 PM
    Friday, June 26, 2009 7:53 PM

All replies

  • It may have false positives if you set a dll to be delay-loaded. You should not reference a 32bit DLL in a 64bit exe though.
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful. This posting is provided "AS IS" with no warranties, and confers no rights.
    Visual C++ MVP
    Friday, June 26, 2009 7:16 PM
  • It may have false positives if you set a dll to be delay-loaded. You should not reference a 32bit DLL in a 64bit exe though.
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful. This posting is provided "AS IS" with no warranties, and confers no rights.
    Visual C++ MVP

    I have no idea what you mean by "false positives". I have never set either Vista system DLL to be delay loaded. If you read my post it is a 32bit exe which appears, according to Dependency Walker, to depend on two 64bit Vista system DLLs, and not the other way around. Also I never directly load kernel.dll or ntdll.dll, so the linker must be, by default, linking these DLLs when I include certain C++ header files.

    The question remains either why the linker is linking to 64bit Vista system DLLs or whether Dependency Walker is erroneously showing this to be the case. I am using the 64bit version of Dependency Walker since I am running Vista 64, so perhaps that version can not adequately tell that a 32-bit module links to 32-bit versions of other modules instead of the 64-bit version of other modules, and it is a Dependency Walker 64-bit problem.
    Friday, June 26, 2009 7:39 PM
  • Evidently the 32bit version of Dependency Walker correctly shows the dependencies for a 32-bit module, while the 64bit version of Dependency Walker can not do so. So the problem is solved and my 32bit console application, when viewed using the 32bit version of Dependency Walker, correctly shows that it is using the 32bit versions of kernel.dll and ntdll.dll in the syswow64 Vista system directory.

    Case solved.
    • Marked as answer by eldiener Friday, June 26, 2009 7:53 PM
    Friday, June 26, 2009 7:53 PM
  • A class library you link to may have Vista-sepcific code (e.g. MFC or .Net).

    Check your system PATH environment variable. Depends.exe may find 64bit dlls from path because you have 64bit dlls path first.

    Please mark the post answered your question as the answer, and mark other helpful posts as helpful. This posting is provided "AS IS" with no warranties, and confers no rights.
    Visual C++ MVP
    Friday, June 26, 2009 7:56 PM
  • I just tried it on my own Vista x64, and I can't reproduce, eldiener. I'd be tempted to reinstall VS2008.
    Friday, June 26, 2009 7:57 PM
  • I just tried it on my own Vista x64, and I can't reproduce, eldiener. I'd be tempted to reinstall VS2008.

    Did you try compiling/linking a 32-bit console application from the Visual Studio 2008 Command Prompt ? When this succeeded, did you try downloading the 64-bit version of Dependency Walker, and looking at your 32-bit console executable using this 64-bit depends.exe ? If you did this, do you not see that the 64-bit version of depends.exe shows your 32-bit console exe having dependencies to 64-bit Windows system DLLs ?

    As I stated in my solution, the 32-bit version of Dependency Walker correctly shows the dependencies for my 32-bit console exe under Vista x64, but the 64-bit version of Dependency Walker does not.

    There is a note in the Dependency Walker FAQ suggesting that the right version, corresponding to a 32-bit or 64-bit module,  is needed to correctly view dependencies on a 64-bit system.
    Friday, June 26, 2009 10:51 PM
  • A class library you link to may have Vista-sepcific code (e.g. MFC or .Net).

    Check your system PATH environment variable. Depends.exe may find 64bit dlls from path because you have 64bit dlls path first.

    Please mark the post answered your question as the answer, and mark other helpful posts as helpful. This posting is provided "AS IS" with no warranties, and confers no rights.
    Visual C++ MVP

    I do not think it is what is first on the PATH because the 32-bit version of Dependency Walker finds the correct dependencies for my 32-bit console application whereas the 64-bit version of Dependency Walker does not, unless executing a 32-bit or 64-bit application gets different PATH environments on Vista x64. If the latter is true, then you are correct and would explain the Dependency Walker situation.
    Friday, June 26, 2009 10:56 PM
  • Yes, I was using the 32-bit Dependency Walker. I didn't see the previous two posts at the moment of my previous post.
    Saturday, June 27, 2009 1:43 AM