How to find out who's causing an access violation error?

Question

I'm getting reports that my app is causing a GPF on some Vista machines. The error message is something like this:

access violation at 0x75784062 ( tried to write to 0x00000006)

In order to fix this, I first need to know exactly who is causing this GPF: my main exe, some third party component, one of my own activex components, a dll, etc...

How can I find this out? What tools can pinpoint the exact module that caused this mess?

Any help would be greatly appreciated.

PS My app is coded in VB6 and my activex controls are written in Delphi 2007.

Answer 1

You can find your answer here, there should be a "Find Error" function which will help you locate the problem

Answer 2

When the program crashes Windows should save a crash dump. You can then load this in WinDbg or, at a pinch, Visual Studio. There are various ways to analyze the dump to find out what went wrong. To get you started:

• Get WinDbg
• Configure the MS symbol server
• Load the crash dump
• Run command "analyze -v"

Answer 3

You could use Process Monitor or Process Explorer, both from the SysInternals site.

Answer 4

Install Debug Diag and monitor your app, he generate DUMP file for you and have analyze to.

Answer 5

My suggestion would be to try either MadExcept link text or Eurekalog link text . These capture the unhandled exception and produce a stack dump at the point where the problem occurs.

No link to these other than as a satisfied customer. MadExcept has enabled me to track down and eliminate some very rare problems in my programs.

Answer 6

I would recommand some kind of Exception-hook, like Eurekalog or madExcept that gives you a nice callstack when exceptions occurs.

Now this want help you much now, of cource...

I have not had any luck with the 'Find error' dialog. Generaly, a consistent failing case and a lot of stepping is the only/fastest/easiest solution. If it is a case of uninitialized pointer or freed object, FastMM4 may help you with the right settings.

Answer 7

Tracking down AVs may be difficult because the real reason may not be in the same point where the exception actually occurs. Some general tips:

1. Look at the address. DLLs (including ActiveX/OCX), are loaded at higher address, usually beyond 0x50000000 (systemm DLLs are usually in 0x70000000 to 0x78000000). It looks your AV happens in a DLL. Remember in latest version of Windows address space load randomization can change addresses for each run
2. A call stack is very valuable to understand how the code got to the AV. Besides EurekaLog and MadExcept, the JCL/JVCL libraries have usueful to obtain those informations. You may need to compile with more debugging informations (and map files) to obtain a useful call stack.
3. Delphi has a Goto address debugging feature that allows to load an application, pause it in the debugger and then jump to an address. But it requires the address didn't change meanwhile (recompiling with modification will probably change the address, and randomization will do as well).
4. If the error is not replicable on your development machine, you can try the remote debugger to debug an application running on another machine.