Please enable JavaScript to view this site.

Memory Validator Help

Navigation: Examples

Finding handle leaks

Scroll Prev Top Next More

 

 

Detecting handle leaks

 

The example program is run once and we use the Memory view to observe and investigate the handle leak.

 

mvMemVal

 

launch nativeExample.exe instructionStep wait until attaching is complete

 

 

nativeExample1

 

menu Handles menu instructionStep Start Thread instructionStep menu File menu instructionStep Exit

 

 

mvMemVal

 

wait for data transfer to complete

 

Memory tab instructionStep Refresh instructionStep shows all leaked memory and any handles that have not been deallocated

 

Common handle leaks might come from forgetting to release a device context (DC), forgetting to reset brushes, pens, and other graphical items, file, DLL or thread handles.

 

One of the leaks is a thread handle:

 

example-leak-handle-item

 

expand the entry instructionStep expand the OnHandlesStartthread entry on the callstack instructionStep the source shows where the handle was allocated in the example application

 

example-leak-handles

 

The top entry in the callstack shows the _beginthreadex() call in threadex.c (MSVCR90D.DLL) where CreateThread() would be called.

 

 

Hey, some leaks aren't leaks!

 

Handles are sometimes shown that aren't really leaked, but where deallocation hasn't been 'seen' by Memory Validator.

 

This is typically because the deallocations are done by kernel internals and don't pass via Memory Validator's hooking mechanism.

 

Other handles might be leaked by errors in 3rd party code.

 

As a result, handles such as bitmaps and icons sometimes show up in the display.

 

For your program, you'll need to decide which handle leaks are important by examining callstacks and using filters to remove unwanted handles from the display.