0

I'm debugging an executable using Application Verifier and WinDbg. I have the "Leaks" test turned on under "Basics". My problem is that when Application Verifier finds a leak, it seems to enter some kind of exception-throwing infinite loop. I get an error like this:

=======================================
VERIFIER STOP 0000000000000900: pid 0x1FE0: A heap allocation was leaked. 

    00000000155A6FF0 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
    0000000000571BE0 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
    0000000012314FD8 : Address of the owner dll name. Run du <address> to read the dll name.
    000007FEF8460000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.


=======================================

But when I press F5to continue debugging I get the exact same message again (and again and again), just with slightly different information for the addresses.

Why is this happening? Is there a way to ignore this leak without turning off the leak checks entirely? As it stands, I can't run my program to completion to test for other issues because Application Verifier gets "hung up" on this leak.

Adam
  • 8,752
  • 12
  • 54
  • 96
  • 1
    Which address differs exactly? Address of the leak only: same line of code produces many leaks (because entered multiple times). Address of the stack: you have many bugs. You could probably write a small script and run it with `sxe -c ... avrf` or so. – Thomas Weller Aug 30 '16 at 23:03
  • @ThomasWeller The first two addresses differ. I held down F5 for like 45 seconds and I finally got to the end of the leak exceptions. So they're several thousand. When I ran the same executable through Dr.Memory I got fewer than 50 leaks though. What's with the discrepancy? – Adam Aug 30 '16 at 23:39
  • @ThomasWeller Further, it seems like the stacks traces, aside from having slightly different addresses, are the same. It's a bunch of third party libraries being unloaded. – Adam Aug 30 '16 at 23:41
  • So the first line is where the leak happened (eg where the thing that wasn't freed went out of scope) and the second line is the stack trace of where the allocation that was leaked occurred? – Adam Aug 30 '16 at 23:46
  • Basically yes. The second line is a pointer to a list of addresses which make the call stack. `dps` helps (**d**ump **p**ointer-sized data and resolve addresses to a **s**tack) – Thomas Weller Aug 31 '16 at 06:48

0 Answers0