Reputation: 94549
I'm involved in various C++ projects (mostly using MSVC6 up to MSVC10) in which we recently found a few handle leaks (thread handles as given by the CreateThread
function). I suspect that there are plenty of other handles being leaked as well and I'd like to integrate a test which verifies that no handles are leaked into our nightly test results.
My idea was to develop a DLL which instruments the relevant kernel32.dll functions (CreateThread, OpenProcess, CreateProcess and a dozen more) as well as the CloseHandle
function. The DLL would then, for each handle being acquired, memorize a backtrace. At the end of the process, the DLL would print all backtraces of handles which weren't closed to some sort of log file, which could then be parsed by the test framework.
This will of course also yield backtraces for all handles which are still reachable (so technically, they didn't leak - maybe the author intended that the OS reclaims them when the process terminates) but I Guess explicitely closing them doesn't hurt - especially since we already have some nice RAII wrappers for this stuff, we just don't use it as much as we should.
Now I'm wondering - this seems like a fairly straightforward approach; maybe somebody here is alware of a library which already does this?
Upvotes: 6
Views: 4730
Reputation: 2407
I've played around with Deleaker and had success with memory and handle leaks. It can be used within Visual Studio or on its own. From the Deleaker website:
It doesn't matter what type of leaks occured, Deleaker finds them all: memory leaks (produced by heap, virtual memory, or OLE allocators etc.), GDI leaks, leaks of Windows USER objects and handles."
Upvotes: 0
Reputation: 2272
We us Memory Validator at my current workplace. It can be configured to track every memory allocation, COM invocation (and ref count), and handles. You start it up, and either have it launch the code you need to validate or attach to running code you want to validate. From that point onward, it is tracking whatever resources you told it to track. When the code exits, it will then have a report of whatever resources it was tracking that wasn't de-allocated, and where they were allocated. It is a commercial product, but it does have a trial period so you could test it and see if it meets your needs. It has been somewhat helpful to myself and co-workers when we've had troublesome leaks in complex situations, but it isn't a magic solution to itself. Good leak hunting techniques are still needed to be followed, it just gives you additional information on which allocations are still hanging around and where they came from.
Upvotes: 1
Reputation: 90
If you have read the Pushing the Limits of Windows article then you would have seen that it mentions the WinDbg !htrace extension which I think fulfills your first requirement for instrumenting the relevant kernel32.dll functions related to handle creation.
To automate the call to !htrace you could embed the debugger engine in your test harness or you could use something like PyDbgEng to launch your application and call the !htrace extension and then collect the stacks when the application finishes. There is an example of this type of automation with PyDbgEng but with the registry functions at http://pydbgeng.svn.sourceforge.net/viewvc/pydbgeng/trunk/PyDbgEng/Examples/RegMon.py?view=markup but I think you could use this example to call an extension see (dbg.idebug_control.CallExtension) in the example.
Upvotes: 1
Reputation: 32125
Mark Russinovich explains in his series to Pushing the Limits of Windows how to better deal with handles and how to track handle leaks.
He is mentioning Windows Debugger and Application Verifier, and he is explaining how you can use that to track your handle leaks down.
In the same page, he mentions also a neat feature of his well-known Process Explorer that is flashing green and red for processes creating / closing handles.
Upvotes: 4
Reputation: 14003
This is definitely possible, but I don't think there's a library that does it yet.
The easiest way, I think, would be with Application Verifier. You can get it from Microsoft's Debugging Tools for Windows. Configure it to track your application's handles, run your application in a debugger for a bit, and then a list of handles will be dumped when your application exits.
Another way to do it, without Application Debugger, would be to set a breakpoint or pause before your application exits. While the application is paused, use something like Process Explorer to obtain a list of all open handles.
For your purposes, I think the latter would be the better choice. I'm not sure of any automated tools that use the debug output. You can use some functionality of the WDK to retrieve a list of the current process (or another process's) open handles, but it is a bit complicated.
Upvotes: 3