System.AccessViolationException from unmanaged code?

Question

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 a

Answer 1

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.

Answer 2

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.