Tracing all DLL loading and initializations in C++/CLI

11
votes

I have a complex C++/CLI application with numerous modules (a few dozens), some managed some unmanaged. Recently we switched from Visual Studio 2013 to Visual Studio 2015. It's working on some computers but not on others.

When the program isn't working, it crashes even before the first line of main. It reports an Access Violation Exception in _onexit . When ignoring some of the exceptions and assertions I see that a <Module> threw a TypeInitializationException .

Problem is - I have no idea which one. I can see when DLLs are loaded in the Output window. The last DLL to load is System.dll - surely my bug is not there. So I need a way to trace static variable initialization in managed DLLs so I can figure out which DLL is problematic, then I can track down the problematic initialization.

How can I do that?

1
visual-studiodebuggingc++-cli
Focus less on the question "What module?" and more on the question "What type didn't load?" The TypeInitializationException should have that information in its details. You should also have a stack trace. - Ben Voigt
Probably you have a static class or a static member which fails on main entry. It can be a logger or a singleton object. Etc. - Y.Doktur
@BenVoigt, unfortunately the debugger doesn't catch the exception, as it happens after the GPF, so I can't really say which type it is at an "unknown" module. I suspect it's <Module> which is a C++/CLI type containing all of a modules global variables and functions. So I need to trace the initializations. - zmbq
@Y.Doktur of course this is the problem, I just don't know which one it is out of all the practically hundreds of static variables in the code. And searching for it by disabling each one (even in a binary search fashion) will take weeks. - zmbq
This rings a bell, I'd have to see the stack trace to positively identify it. The CRT rewrite in VS2015 suffers from static initialization order fiasco problems. Most typically triggered in a C++/CLI app that targets System::Windows::Forms, it is the module initializer that keels over. Survival guide is here, the hack discovered by @pianoslum (overriding the entrypoint) is the one you probably want. - Hans Passant

1 Answers

3
votes

Well, i feel a little stupid, but in a problem while loading with a type load exception I used fuslogvw.

I think it should give you the order of dll bindings and therefore a first impression.