locked
How to check NET application dependency? RRS feed

  • Question

  • I have a WPF application which target to 64-bit. It can start on my PC, but failed to start on target without any info. I guess it is dependency issue. Both the develop PC and target PC are same (Windows 7 64-bit with same hardware profile).

    I try to use dependency walker (64-bit). But it give me nothing:

    If I use dependency walker (32-bit). Same result. It seems the dependency walker does not work for Windows 64-bit.

    So, in general, which tool to use to find why my application not start in target PC?

    • Moved by Leo Liu - MSFT Monday, January 30, 2012 7:28 AM Moved for better support. (From:Visual C# General)
    Friday, January 27, 2012 10:10 PM

All replies

  • 64-Bit Dependency Walker does work on Windows 64-bit.

    What exactly is happening on the 64-bit machine? It sound slike it's probably not a dependency issue - especially because those typically do display exception messages.


    Check out My Blog. Now updated to actually work!
    Friday, January 27, 2012 10:13 PM
  • "64-Bit Dependency Walker does work on Windows 64-bit."

    -really?

    I have write a dummy winform application by using visual studio 2010. No any code added. Just change project build tartget to x64. By using dependency walker, I got:

     

    I still cannot see any module it depends.

    Friday, January 27, 2012 10:44 PM
  • That may be an entirely different issue, but I've used Dependency Walker 32-bit and 64-bit successfully for years now without problems. In any case, I believe that's a red herring - missing dependencies will nearly always throw exceptions. You should either have an error message popping up or, if not that, an error showing up in your event log.

    If your application is just starting and immediately stopping, it doesn't sound like a missing dependency. It sounds like you either have an infinite loop (stack overflow) or possibly a permissions problem. The best starting point would be to see if any messages are written to the event log when you try to start your application and it closes.


    Check out My Blog. Now updated to actually work!
    Friday, January 27, 2012 10:52 PM
  • I'd recommend WINDBG to capture the exception at the OS layer to see what's going on.  When an application is started the OS transfers control the the "Loader" dll which does a few major things.  Chances are you are not getting out of the loader.  WINDBG will show the error which may not be seen at the application layer.

    Interesting that you posted this because just yesterday we found a Loader issue when starting an application.  We put WINDBG on and found that there was a reference to a DLL that was not to be found.  In our case we traced it back to an Installshield build problem.


    JP Cowboy Coders Unite!
    Friday, January 27, 2012 10:57 PM
  • Is the Framework installed on the target machine?
    Mark the best replies as answers. "Fooling computers since 1971."

    http://thesharpercoder.blogspot.com/

    Friday, January 27, 2012 11:45 PM
  • Yes. The framework installed.

     

    By the way, if I build the application in x86 by using studio 2010 project wizard without any code added. dependency walker (x86) works fine.

    But if I change target to x64 and build it, dependency walker (x64) display as above - blank! 

    In both case, program are running fine.

    Monday, January 30, 2012 6:26 PM
  • > I have a WPF application which target to 64-bit. It can start on my PC, but failed to start on target without any info


    you should create a dump file and inspect it.
    see Intro to WinDBG for .NET Developers also take a look at the Session: Debugging .NET Applications with WinDbg
     
     

     

    • Proposed as answer by Malobukv Wednesday, February 15, 2012 9:29 PM
    Monday, January 30, 2012 7:34 PM
  • I think maybe that x64 NET binaries have a different loading mechanism. That x86 dependency list is all rooted in mscoree.dll, and that's not linked as a static dependency on x64. That might not be completely technically accurate, but it's something like that.

    Anyway, what are you trying to do? Why bother with a Win32 type of dependency viewer for managed code? You need Reflector or ILDasm to see NET dependencies.


    Phil Wilson
    Monday, January 30, 2012 11:54 PM