First-chance exception at 0x782260ec in xxx.exe: 0xC0000005: Access violation

Question

My application crashes after some time but I can't find any pattern. I was able to get my hands on crash dump. Application runs on Windows Mobile 6.5. It is written in C#. It uses Imaging API , PInvoks and lots of threads.

When I debugged that dump with Visual Studio 2008, in output it displayed "First-chance exception at 0x782260ec in xxx.exe: 0xC0000005: Access violation"

Call Stack shows 2 entries. But I can't match any of them to call from my code.

windbg.exe indicates that this error occurs in "netcfagl3_5.dll"

Are there some special techniques to analyze dump files from Windows Mobile??

Answer 1

'First-chance exception' usually means an exception that has been handled by user code. If you're using the Vosual Studio & the Windows Mobile emulator for debug then you can turn off exception handling. Go to Debug > Exceptions and check the 'Thrown' column for Win32 Exceptions. Then run the program and try and get it to fall over again.

When the debug runs it will halt execution and break to the debugger when it hits that 'first-chance exception' allowing you to see what is causing that, and see if it's in any way related.

The 'netcfagl3_5.dll' library is part of .NET CF, not your code, which is why you can't match up the debug symbols.

Answer 2

0xC0000005: Access violation means that one of your p/invokes are incorrect. The call tried to write to a memory area which it doesn't have access to (which is typical if the definition is incorrect).

Your dump should contain a stack trace too?

Answer 3

You will need to download windbg, Visual Studio 2008 won't do Post Mortem .NET debugging.

If your development machine is 64-bit, see " How to use Windbg to debug a dump of a 32bit .NET app running on a x64 machine "

Otherwise, see Post Mortem Debug under Windows Mobile with WinDbg . also do some searching on "Windows Mobile Post Mortem Debug".

The best (by far) and easiest way, though is to reproduce this issue while running on the debugger. Post mortem .net debugging is NOT easy.

-PaulH