我嘗試使用 !htrace 來檢測一些句柄泄漏（我之前在 gflags 用戶模式呼叫堆疊中啟用）問題是，即使它向我顯示了句柄分配的呼叫堆疊，它們的大小也被限制為 14 幀。Windbg 命令“.kframes largeLimit”沒有幫助。
uj5u.com熱心網友回復：
你說的只有 14 幀是什么意思？
啟用 !htrace for htrace 以收集跟蹤后，您是否進行了足夠的操作？
據我所知，沒有 14 幀限制
只是為了確認我將 cdb 附加到記事本 的運行實體并記錄了跟蹤
cdb -pn notepad !htrace -enable
.logopen d:\htrace.txt
g
open 關閉了幾個選項卡 about , plugins 等，可能會
用 ctrl c來收集突破
！htrace 并退出和 awk grepped htrace.txt
我可以看到很多痕跡和幀 > 14 oa log 1.61 MB 大幾分鐘
:\>ls -lag *.txt
-rw-r--r-- 1 197121 1691957 Oct 19 23:01 htrace.txt
:\>awk "/Handle = /" htrace.txt | tail
Handle = 0x0000000000000484 - CLOSE
Handle = 0x0000000000000484 - OPEN
Handle = 0x0000000000000480 - CLOSE
Handle = 0x0000000000000480 - OPEN
Handle = 0x000000000000047c - CLOSE
Handle = 0x000000000000047c - OPEN
Handle = 0x0000000000000478 - CLOSE
Handle = 0x0000000000000478 - OPEN
Handle = 0x0000000000000474 - CLOSE
Handle = 0x0000000000000474 - OPEN
:\>grep -iE "parse|dump" htrace.txt
Parsed 0x56C stack traces.
Dumped 0x56C stack traces.
:\>awk "/Handle =/{print NR-1;NR=0}" htrace.txt | sort | uniq
13
14
15
16
17
18 <<<<<<<<<<<<<
3
:\>
一個這樣的跟蹤包含 15 幀如下
Handle = 0x00000000000004a0 - CLOSE
Thread ID = 0x0000000000002488, Process ID = 0x0000000000000644
0x00007ffa5769d084: ntdll!NtClose 0x0000000000000014
0x00007ffa54fe3c56: KERNELBASE!RegCloseKey 0x00000000000000b6
0x00007ffa566e48d3: shcore!CRegistrySource::Release 0x0000000000000043
0x00007ffa54962773: windows_storage!CProgidArray::EnumerateCapableFileHandlers 0x00000000000001d3
0x00007ffa54961ce6: windows_storage!CAssocProgidElement::_GetUserChoice 0x0000000000000082
0x00007ffa549629ac: windows_storage!CAssocProgidElement::_MapExtensionToUserDefault 0x0000000000000204
0x00007ffa54962206: windows_storage!CAssocProgidElement::_InitSource 0x0000000000000066
0x00007ffa5496d6ac: windows_storage!CAssocShellElement::SetKey 0x000000000000005c
0x00007ffa5495a957: windows_storage!AssocElemCreateForClass2 0x0000000000000083
0x00007ffa5495a6d1: windows_storage!CFileAssocList::CreateAssoc 0x00000000000000d1
0x00007ffa5493e17f: windows_storage!CAssocListBase::_GetOrCreate 0x000000000000006f
0x00007ffa5495e773: windows_storage!CAssocListBase::GetAssoc 0x00000000000000a7
0x00007ffa5495e657: windows_storage!CFileAssocList::_IsLink 0x0000000000000043
0x00007ffa5495e5bb: windows_storage!CFileAssocList::GetAssocTable 0x000000000000001b
0x00007ffa5495ebde: windows_storage!CAssocListBase::EnumerateElements 0x00000000000000de
--------------------------------------
Handle = 0x00000000000004a0 - OPEN
根據現在消失的 ertwhile windbg msdn 新聞組參考參考副本的帖子，它似乎是硬編碼的最大 16 幀
"Dan Mihai [MSFT]" dmihai@xxxxxxxxxxxxxxxxxxxx wrote in message news:#NGSSnSnGHA.4604@xxxxxxxxxxxxxxxxxxxxxxx
Small correction: the !htrace stack traces are captured by the OS kernel (not ntdll). The greatest thing about that is that the order of these traces is "fully accurate". For example, if process A is closing a handle inside process B (using DuplicateHandle), with handle tracing enabled for B you will get a log entry for the cross-process CLOSE operation. If stack tracing would have been implemented in user-mode (e.g. inside ntdll), process B's ntdll would not get "notified" about the cross process CLOSE and B's handle would go away without any trace in the !htrace log. That would reduce the value of !htrace.
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.
The kernel doesn't currently allow very deep stack traces because the array of traces is stored in non-paged pool, a very expensive system resource.
Dan
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/326474.html