Access violation while the program was idle - not trace information to track down the bug

Question

I have a program that just popped up an AV. Until now the Eureka Log could find the source code line that generated the error but now it displays only this:

Access violation at address 7E452E4E in module 'USER32.dll'. Read of address 00000015.

Call Stack Information:
--------------------------------------------------------------------------------------------
|Address |Module          |Unit         |Class|Procedure/Method                     |Line  |
--------------------------------------------------------------------------------------------
|Running Thread: ID=2640; Priority=0; Class=; [Main]                                       |
|------------------------------------------------------------------------------------------|
|77F16A7E|GDI32.dll       |             |     |IntersectClipRect                    |      |
|7E433000|USER32.dll      |             |     |EditWndProc                          |      |
|7E42A993|USER32.dll      |             |     |CallWindowProcA                      |      |
|7E42A97D|USER32.dll      |             |     |CallWindowProcA                      |      |
|7E429011|USER32.dll      |             |     |OffsetRect                           |      |
|7E4196C2|USER32.dll      |             |     |DispatchMessageA                     |      |
|7E4196B8|USER32.dll      |             |     |DispatchMessageA                     |      |
|00625E13|Amper.exe       |Amper.DPR    |     |                                     |76[16]|
|7C915511|ntdll.dll       |             |     |RtlFindActivationContextSectionString|      |
|7C915D61|ntdll.dll       |             |     |RtlFindCharInUnicodeString           |      |
|7C910466|ntdll.dll       |             |     |RtlFreeUnicodeString                 |      |
|7C80B87C|kernel32.dll    |             |     |IsDBCSLeadByte                       |      |
|7C9113ED|ntdll.dll       |             |     |RtlDeleteCriticalSection             |      |
|7C80EEF5|kernel32.dll    |             |     |FindClose                            |      |
|7C901000|ntdll.dll       |             |     |RtlEnterCriticalSection              |      |
|7C912CFF|ntdll.dll       |             |     |LdrLockLoaderLock                    |      |
|7C9010E0|ntdll.dll       |             |     |RtlLeaveCriticalSection              |      |
|7C912D19|ntdll.dll       |             |     |LdrUnlockLoaderLock                  |      |
|7C9166C1|ntdll.dll       |             |     |LdrGetDllHandleEx                    |      |
|7C9166B3|ntdll.dll       |             |     |LdrGetDllHandle                      |      |
|7C9166A0|ntdll.dll       |             |     |LdrGetDllHandle                      |      |
|7C912A8D|ntdll.dll       |             |     |RtlUnicodeToMultiByteN               |      |
|7C912C21|ntdll.dll       |             |     |RtlUnicodeStringToAnsiString         |      |
|7C901000|ntdll.dll       |             |     |RtlEnterCriticalSection              |      |
|7C912CC9|ntdll.dll       |             |     |LdrLockLoaderLock                    |      |
|7C912CFF|ntdll.dll       |             |     |LdrLockLoaderLock                    |      |
|7C9010E0|ntdll.dll       |             |     |RtlLeaveCriticalSection              |      |
|7C912D19|ntdll.dll       |             |     |LdrUnlockLoaderLock                  |      |
|7C90CF78|ntdll.dll       |             |     |ZwAllocateVirtualMemory              |      |
|7C90CF6E|ntdll.dll       |             |     |ZwAllocateVirtualMemory              |      |
|7C9010E0|ntdll.dll       |             |     |RtlLeaveCriticalSection              |      |
|7C80BA57|kernel32.dll    |             |     |VirtualQueryEx                       |      |
|7C80BA40|kernel32.dll    |             |     |VirtualQueryEx                       |      |
|7C80BA81|kernel32.dll    |             |     |VirtualQuery                         |      |
|7C901000|ntdll.dll       |             |     |RtlEnterCriticalSection              |      |
|7C912CC9|ntdll.dll       |             |     |LdrLockLoaderLock                    |      |
|7C912CFF|ntdll.dll       |             |     |LdrLockLoaderLock                    |      |
|7C9010E0|ntdll.dll       |             |     |RtlLeaveCriticalSection              |      |
--------------------------------------------------------------------------------------------

The program was totally idle while I got the error and its window was hidden by other windows. FastMM is active and set to full debug but it indicates no memory overwrite. Any hints about how to find the origin of this AV?

---

Win XP, Delphi 7

Answer 1

I don't see an EditWndProc() method in user32.dll, but Delphi has a couple -- one dealing with combobox messages and one dealing with tree views. Given MS's comctrl mess, I'd guess you have a tree view?

Check your tree view stuff. Given IntersectClipRect's parameters, it's easy to guess that it's being passed an invalid device context -- so...are you doing any custom painting for your tree view? If so, are you checking to make sure the canvas handle is ! NIL before you begin painting (try assertions if nothing else)?

Answer 2

I just wonder what's on line 76[16] in Amper.exe... That line number might be a hint of the location of the error.
Then again, when it's just happening during an idle moment then it basically happens when the system is processing Windows messages like the mouse moving, keyboard events, timer updates and a lot more.
It sometimes helps to search for the error message plus code. I've done a quick scan and found this KB from MS which suggests that this kind of error can happen when you call certain Windows API's with invalid parameters. But this KB doesn't apply to your error. Still, it gives you an idea about what to check: any Windows API call you make in your own code.
Does it also generate this exception in the IDE, while you're debugging?

Answer 3

That's what EurekaLog does when it has nothing to work with. You need to rebuild and have the linker produce a detailed map file. That's how it knows what to apply its stack trace to.