System.AccessViolationException from unmanaged code?

I'm writing this library that implements some basic audio player features in C++/CLI via the Media Foundation framework that will be consumed by managed code. I can play audio, stop, pause, etc just fine. For anyone who is not familiar with Media Foundation, the media session posts events that you can handle for notifications. This is done by calling BeginGetEvent on the session object with an IMFAsyncCallback object. The IMFAsyncCallback defines the method Invoke(IMFAsyncResult) that you should implement to handle the events. When an event occurs, the invoke method is called by the session object on a work thread with an IMFAsyncResult object that you can query for the event info. This result object is created and owned by the event thread.

In my implementation of Invoke, whenever I try and do anything (that 开发者_如何学编程includes just calling QueryInterface or something) with the IMFAsyncResult object that I am passed, I get a System.AccessViolationException. The object I have implementing IMFAsyncCallback is a basic C++ class (not managed) allocated on the CRT heap and the events are posted on a thread owned by the session object also allocated on the CRT heap.

1. What could be causing this exception?

2. Why am I getting a .NET managed exception thrown from code that is implemented in plain old C++? Is that just what happens when you have a mixed mode assembly?

Capture a crash dump, then load it into VS 2010 or WinDbg for analysis, and all shall be revealed. VS 2010 will be easier, but WinDbg might be more effective.

Since using WinDbg is the more complicated option I'll elaborate on that (choose the 32-bit or 64-bit versions of the following according to your target platform):

• Download and install Debugging Tools for Windows
• Configure debugging symbols for the Microsoft Symbol Server

.sympath srv*<SymbolCacheDir>*http://msdl.microsoft.com/download/symbols

• Load the crash dump file into WinDbg (File->Open Crash Dump...)
• Configure debugging symbols for your modules

.sympath+ <PrivatePdbDir>

• Load SOS extensions into WinDbg

.loadby sos mscorwks; * fw 2-3.5

or

.loadby sos clr; * fw 4

• Download, extract and load SOSEX extensions into WinDbg

.load <Sosex32or64Dir>\sosex

• Let WinDbg do the analysis

!analyze -v

• Use SOSEX to show the current thread stack (including both managed and unmanaged frames)

!mk

This will most likely answer your questions.

Sounds like you have an easy repro of this - you should be able to debug the problem by attaching the debugger while the program is running and enabling Access Violation to be trapped at the point at which it occurs. Often, libraries wrap this and surface it as another type, and the original site of the exception is not apparent.

To attach to your process from Visual Studio see here. When you attach to your rogue process, make sure you select the options to debug native and managed code. Make sure symbols for your assemblies and DLLs are available in the Symbol path,as far as you can (some may not be available if they are third-party code).

To alter Exception config so that access violation is debuggable at source, see here.