Catch the worm 2:windows the context of a program handle disclosure

As a programmer, the development process is the basic skill, and the debugging program is one of the necessary skills. Software will undergo various stages of testing after the development of the main function, before it is released. In the test process, there are more likely to be memory leaks, handle leaks, abnormal crashes, etc. are non-functional software bugs. and windows as a fairly mature platform, for software debugging also support is in place. What you want to record today is a handle leak problem for a module of this survey.

There are many articles about handle leaks online, many of the books on debugging are also explained, and some are more detailed. I've solved this kind of problem before, so I don't care. First of all, the basic situation: the work machine is the Windows 7 64bit Pro version of the sp1,windbg use of 32bit version, the problem module is 32bit, dependent on a number of external modules, are 32bit, And it contains dbghelp.dll (which explains why it is said separately).

According to the description of the bug, start the operation before the WINDGB, set the Pdb,!htrace open. operation, in the Task manager, found that the debug module handle the number of rubbing against the rise, stop the operation has not seen signs of decline. See this situation, had to break into the WinDbg to see the situation, see!htrace-diff input after the results are immediately dumbfounded. All is a virtual address, without any stack information, immediately think is not the PDB is wrong, lmvm a look, display correct. But the stack that the K shows is really the stack that has the module being debugged. The moment can not think of the problem, then write a demo of their own, see is not the same, finished writing demo Hung WinDbg, the situation incredibly same! This is the feeling is a bit strange, the problem should not be in the debugging program, on the degree of Niang A, without any discovery. In the high-end debugging site someone sent a post, the situation and I, but no one answer how to solve, no fruit. Read books, see are all-in-one, for the above problems encountered, without any mention, no fruit. Accidentally found a tool on the Internet HTTP://PAN.BAIDU.COM/S/1JGIOPQM, can detect memory leaks, handle leaks. The above-written demo use, it really reflects the incident leak point, feel good. Then put the problem module into use. Inject a mistake, said the debugging process has been loaded Dbghelp.dll. That is the point mentioned above, no fruit.

Want to go, and then simply on a 64bit WinDbg, in debugging 32bit demo,!htrace-diff actually show a few lines of stack, switch to x86 mode display, indeed show the createevent words, instantly seem to understand what. Switch the demo compiler condition to 64bit, try again with 64bit WinDbg, and stack all display. Then the leaking module installed on the 32bit machine, with 32bit WinDbg a look. There is a stack of handles not closed. to the bottom.

Why on 64bit machine, 32bit WinDbg debug 32bit process, General function call, all can display the stack, but for the difference handle stack, but do not display, no answer. After this discovery, it is important to focus only on the problem itself, but sometimes it is often that all external factors interfere with our judgment of things, and at this time we should stand at a high altitude and look at the problem, then everything is clear.

Catch the worm 2:windows the context of a program handle disclosure