3

I know if we provide the absolute path to Handle.exe it will list all processes that locked the file.

F:\Softwares\Handle>Handle.exe  D:\Source\sample.dll

Handle v4.0
Copyright (C) 1997-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

test1.exe           pid: 9928   type: File           408: D:\Source\sample.dll
test2.exe           pid: 10840  type: File           6A8: D:\Source\sample.dll
test3.exe           pid: 15788  type: File           374: D:\Source\sample.dll
test4.exe           pid: 10940  type: File           308: D:\Source\sample.dll
test5.exe           pid: 15424  type: File           3FC: D:\Source\sample.dll
test6.exe           pid: 10076  type: File           8AC: D:\Source\sample.dll

Windows 7 64bit

As stated by Handle.exe my sample.dll is locked by 6 different process. I want to know which is the line of code which actually holds the sample.dll from each process. My task is to fix the handle leaks in my mammoth application. So my problem is not fixed to a specific part of program. The task is i have to generate report contains handle leaks diagnose who created it. The leaks are not specific to file , it expands to all system resource like file, registry key, event,Semaphore,Thread ...etc .

I have taken a dump using windbg but I couldn't find how to diagnose the dump file especially for handle leaks. In my search around half a day a couldn't find good tutorial or solution which suites my problem.

Is there any command line tool or any other tool which answers my question.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
Srikanth
  • 980
  • 3
  • 16
  • 30
  • 1
    in a compiled application without readable debugging info (PDB), this is not possible. There is no fixed relationship between lines of code and the assembler statements it generates at compile-time, so its not generally possible to track the statements back to high level code. With fully interpreted langagues, and some hybrid-interpreter runtimes, it may be possible, but this is far fro universal. – Frank Thomas Feb 10 '15 at 12:33
  • Furthermore even if it was possible. It could be any number of lines in theory. What problem are you trying to solve exactly? – Security Hound Feb 10 '15 at 13:03
  • @Ramhound in my example above D:\Source\Sample.dll is locked by 6 process. In my application this was loaded by some part of code and is not released properly. There were similar problems like handle leaks , file, registry key, event...etc . My problem is which part of code is locking the handle? I want a practical solution – Srikanth Feb 10 '15 at 13:11
  • Usually, DLL loading is handled outside program code. you just include a dll, and the compiler and loader take care of the rest. For (non-dll) external resource leaks, correctly implement try-finally structures to ensure the release of the resources even if a crash occurs. short lived Locks occur at read time, and longer term locks occur when the file is opened for write, or actively being written to. – Frank Thomas Feb 10 '15 at 13:29
  • @Srikanth - Every time you load a symbol from the dll then call that code the you create a dependency on the dll. Do you have the debugging information for these processes? – Security Hound Feb 10 '15 at 13:41
  • @Ramhound yes i have PDB's please check my updated post. – Srikanth Feb 10 '15 at 13:44

2 Answers2

4

You are using the wrong debugging tool. You want to read this article, it goes into great detail how to get a stack-trace for leaked handles with the !htrace debugger command. Also covered by this existing SO question.

You'll see "Debugging Tools for Windows" mentioned often. It is no longer a separate download but included in the Windows SDK install.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thank you I have updated my post , also as suggested by you i was already using windbg and i have no clue , to go to code level using windbg. As the results from windbg is always a memory location of Object reference tables in kernel. – Srikanth Feb 13 '15 at 11:36
0

I think you can find the culprit by using procmon, another Sysinternals tool.

It will make your day, only problem is in case the handle creation rate is very slow - you can not record system activity for more than few tenths of minutes... except your system has a huge amount of memory installed.

Once you have recorded your events (don't forget to run it as Administrator, and to stop it after few minutes, I prefer to analyze the captured data after stopping it usually) go to the menu "Tools" -> "File Summary" and find the accessed files there.

Double clicking on a file (or on a directory, in the folder view, and so on... doubleclicking "anywehere"), will add a filter in the procmon view and let you analyze every single operation regarding it, performed by any process running in the system.

If you double-click on the single operation, you will be able also to view the backtrace of the stack in the context of that syscall, further other details regarding the I/O (in this specific case) operation.

Sigi
  • 4,826
  • 1
  • 19
  • 23
  • You can set up filters and "Drop Filtered Events" to allow procmon to run for longer periods without hitting memory limits. – Tim Sparkles Jul 27 '15 at 23:13