It seems that "!htrace -diff" can only show 16 frames. How can I increase the frame counts in the stack traces? The following is one of the handles leaked detected by !htrace -diff. I can't read anything from it without a complete stack trace.
Handle = 0x00000f7c - OPEN Thread ID = 0x00001cc4, Process ID = 0x00009f20 0x01b8dad8: +0x01b8dad8 0x018c6e93: +0x018c6e93 0x7788179a: +0x7788179a 0x000a20bb: +0x000a20bb 0x753ab069: +0x753ab069 0x7539cf87: +0x7539cf87 0x75322776: +0x75322776 0x7539d07e: +0x7539d07e 0x7539c549: +0x7539c549 0x778ae707: +0x778ae707 0x7785c32e: +0x7785c32e 0x77a2ff66: ntdll!ZwCreateEvent+0x00000012 0x69bffc58: verifier!AVrfpNtCreateEvent+0x0000006b 0x77390d93: KERNELBASE!CreateEventExW+0x0000006e 0x773911c6: KERNELBASE!CreateEventW+0x00000027 0x69bffd8f: verifier!AVrfpCreateEventW+0x00000078
The maximum depth of the stack trace is currently hardcoded to 16 (although it's possible it will change in the future). Also, that includes a few entries for the kernel-mode portion of the stack trace. Those stack trace entries can be displayed by kernel or driver developers by using !htrace in a kernel debugger. So getting around 11 user-mode entries for each of your traces sounds accurate.
Unfortunately you can't.
Assuming that you have symbols set up correctly, I see the following possibility
Some of the traces reported by !htrace may be from a different process context. In this case, the return addresses may not resolve properly in the current process context, or may resolve to the wrong symbols.
Source: WinDbg help (
This can happen if a different process injects handles into your process and the addresses correlate to that process. In this case, the process ID listed by
!htrace does not match the process you're debugging (type
| (pipe) to get the process ID).
In such a case, you can attach to the process (
0n is default here) and try to get the remaining callstack from there, but I never did this myself.
User contributions licensed under CC BY-SA 3.0