I have a C# WPF application that is suddenly throwing an exception on startup, and I cannot figure out why. The exception is a C++ HRException, and it occurs in MSCORLIB in CreateInstanceSlow(), which is called from CreateInstance(), which is called from BamlRecordReader.CreateInstanceFromType() in the System.Windows.Markup assembly. I moved all of my assemblies from this application, as well as a third party library I had just upgraded, and finally got the app to run again (although it was just a shell). Then I added the third party lib back in, no problem, then added each one of my assemblies back in, adding each as a reference, and declaring a variable of a type defined in that assembly in my main app, and this worked OK. So I blew all that away and reverted to what was checked in, and I am back to the exception again, so I don't think it's a DLL that cannot be found, or one that's blowing up on initialization - but I cannot figure out what it is. I tried descending the callstack and looking in the parsing functions, but the debugger tells me that I cannot examine most of the variables due to there being a native frame at the top of the stack. I'd really appreciate any tips on how to go about figuring out what XAML is actually being parsed when the exception is thrown, as well as hearing fro anyone else who has had similar issues.
While I would still appreciate tips on how to debug these exceptions, I was able to track this one down. One of my DLLs used a class from another DLL, that was being built incorrectly (though I'm still not sure why). Once I was able to rebuild that DLL and the one that consumed it, and then rebuild my app, everything worked. But what is frustrating is that I was blindly stabbing in the dark, using trial and error to figure out which DLL (and which class in that DLL) was causing the problem. And the only thing the system could tell me was that there was some kind of an error in some XAML somewhere. I should mention that these assemblies that I was using in my C# app were written in C++/CLI, and contained native C++ code - but I do not think this was really an interop problem. So anyway, additional hints on how to really figure out what is really wrong would be greatly appreciated!
I would start with ensuing VS has native and managed debugging enabled, and a symbol server working. This should at least allow a stack trace.
Another option might be to force a process dunp and using WinDBG (along with lots of blog/book reading that cover this kind of debugging).
Also, does the XAML load is the simpest possible wrapper (i.e. just enough to use a XamlReader instance)?