How can I get all frames of stack traces in "!htrace -diff" result?

Question

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

Answer 1

This link point to this one Which tells that basically it is hard coded.

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.

Answer 2

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 (.hh !htrace)

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 (.attach 0x<pid>, 0n is default here) and try to get the remaining callstack from there, but I never did this myself.