Search code examples
.netvisual-c++c++-cliaccess-violationms-media-foundation

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?

Solution

  • 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):

    .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.