I've got a .NET plugin (written in C# & VB.NET) exposed via COM and loaded into an application built using native code (C++). We're working on a 64 bit compatibility release, and when the application exits we're seeing a crash screen from the application.
If I run the application from a Visual Studio debug session the crash isn't caught by the debugger, although if I had to hazard a guess the crash happens while the debugger is attached, because I'm getting the option to start a new debug session, but it won't let me use the session with which I started the application.
I've tried stripping out the guts of the add-in and loading a minimal bootstrap version, at which point the crash disappears, so it does appear to be an issue with the plugin itself. I've tried tagging all of the AppDomain.UnhandledException, Dispose() and destructor methods I can find with MessageBox.Show() just to try and identify a culprit, but I'm getting nothing from any of them.
Couple of helpful details:
We use three main DLLs: a bootstrapper DLL responsible for loading the other two, a version-specific copy of the application interface layer DLL, and a primary business logic DLL which interacts with the application interface layer via a set of .NET interfaces.
We interact with the application through a set of PIAs that are updated with each application release. The bootstrapper references the oldest of these on 32 bit systems, and that works fine (the bootstrapping API is minimal and never changes). On 64 bit systems, I've tried both the oldest and newest 64-bit versions and both experience these crashes.
Given the tie to the main business logic layer, I don't see how this could be other than an exception being raised from .NET. Is there another possible source that I'm missing? More generally, is there a way of attaching a debugger that will handle this configuration, or a tool that will at least let me take a process dump at the point of the crash? WinDbg and Visual Studio both fail to do the job. WinDbg raises an access exception as soon as I attach and hit Go, presumably because it's mixed-mode debugging, and Visual Studio loads a debugging workspace but doesn't appear to actually attach to the process, so it just opens an empty workspace with no active code.
Edit:
Progress! I've tied the crash to a RichTextBox control. If I do anything with the control beyond loading it into the application, the app crashes on exit. Not sure where that gets me, but it's probably useful if you know things about things.