Geek Answers Handbook

System.AccessViolationException from unmanaged code?

I am writing this library that implements some of the basic functions of an audio player in C ++ / CLI through the Media Foundation environment, which will be consumed by managed code. I can play sound, pause, pause, etc. For those new to the Media Foundation, a media session publishes events that you can process for notifications. This is done by calling BeginGetEvent on a session object with an IMFAsyncCallback object. IMFAsyncCallback defines the Invoke method (IMFAsyncResult) that should be implemented to handle events. When an event occurs, the call method is called by the session object in the workflow with the IMFAsyncResult object, which you can request for information about the event. This result object is created and belongs to the flow of events.

In my Invoke implementation, when I try to do something (including just calling QueryInterface or something else) with the IMFAsyncResult object that I passed, I get a System.AccessViolationException. The object that I am implementing IMFAsyncCallback is the C ++ base class (unmanaged) allocated on the CRT heap, and events are placed on the thread belonging to the session object also allocated on the CRT heap.

  • What can cause this exception?

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

+1
visual-c ++ access-violation c ++ - cli ms-media-foundation
source share
2 answers

Capture a crash dump , then load it into VS 2010 or WinDbg for analysis, and everything should be open. VS 2010 will be simpler, but WinDbg may be more efficient.

Since using WinDbg is a more complicated option, I’ll talk about this (choose a 32-bit or 64-bit version of the following according to your target platform):

  • Download and install Debugging Tools for Windows

  • Configuring Debug Symbols for Microsoft Symbol Server

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

  • Download the crash dump file in WinDbg (File-> Open Crash Dump ...)

  • Setting up debugging symbols for your modules

    .sympath+ <PrivatePdbDir>

  • Download SOS Extensions to WinDbg

    .loadby sos mscorwks; * fw 2-3.5

    or

    .loadby sos clr; * fw 4

  • Download, extract and load SOSEX extensions in WinDbg

    .load <Sosex32or64Dir>\sosex

  • Let WinDbg do the analysis

    !analyze -v

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

    !mk

This will most likely answer your questions.

+6
source share

It seems that you have an easy way to reproduce this - you should be able to debug the problem by attaching a debugger while the program is running and allowing you to grab access to the Access Violation at the moment this happens. Often libraries wrap this up and treat it as a different type, and the source exception site is not obvious.

To connect to your process from Visual Studio, see here . When you join the rogue process, make sure you select options for debugging your own and managed code. Make sure that the symbols for your assemblies and DLLs are accessible in the symbol path as much as possible (some may not be available if they are third-party member code).

To modify the Exception configuration so that the access violation is debugged at the source, see here .

+1
source share

More articles:


All Articles