转储分析问题
我试图捕获地址的堆栈跟踪，但它总是向我显示任何内容，
我的问题是分析内存泄漏，所以我查询了所有堆静态信息，然后查询最高分配的内存，它返回了我很多分配，
我尝试通过“!heap -p –a ####”搜索多个分配地址，####是地址。 但它永远不会返回任何调用堆栈，
但如果我搜索内存中的该地址/任何其他地址，它会向我显示类似的分配。
另外，如果我尝试运行此命令“dt ntdll！_DPH_HEAP_BLOCK StackTrace ####”，它会返回 NULL 堆栈跟踪。
是因为应用程序的页堆未启用吗？？？
I tried to catch the stack trace of an address, but it always show me nothing,
my issue is analyse memory leak, so i have queried all heap statics and then queried highest allocated memory, it returned me lot of allocation,
and i tried to search many of allocation address by “!heap -p –a ####“, #### is adress.
but it never return me any call stack,
but if I search this address/any other adresses in memory, it shows me similar allocation.
also if i try to run this command “dt ntdll!_DPH_HEAP_BLOCK StackTrace ####,” , it return me NULL stack trace.
is it because of page heap for application is not enabled????
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于本机内存问题，您无法轻松使用转储来确定根本原因。
Microsoft 有一个用于 32 位进程的工具 DebugDiag，
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en
您可以使用它来跟踪本机内存一些典型场景中的泄漏，
http://support.microsoft.com/kb/919790
此外， Microsoft 支持团队的参与可以加快根本原因分析，
http://support.microsoft.com
For native memory issues, you cannot easily use dumps to determine the root cause.
Microsoft has a tool DebugDiag for 32 bit processes,
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en
You can use it to track native memory leaks in some typical scenarios,
http://support.microsoft.com/kb/919790
Besides, involving Microsoft support team can speed up the root cause analysis,
http://support.microsoft.com
这里有很多事情，首先，您将无法获得您无权访问的符号的完整堆栈跟踪，为此您需要没有剥离私有符号的 pdb。
对于 Microsoft 符号，在 WinDbg 中输入“.symfix;.reload”应该可以解决该问题。
其次，虽然您不会获得第三方 dll 的堆栈跟踪，但您会获得自己的应用程序 dll 的堆栈跟踪，但您需要确保带有公共符号的 pdb 与用于生成转储的版本相匹配。
您可以要求客户在 gflags 中生成用户堆栈跟踪并重现错误，或者向您发送包含完整符号信息的 pdb。
还可以在 Visual Studio 中打开转储文件：
实例可能会发现这种方法更熟悉，但您将无法访问 WinDbg 工具，但由于这是事后分析，您可以在 Visual Studio 和 WinDbg 中打开转储，因为您无论如何都不会进行侵入式调试。
There are a number of things here, firstly you will not get a complete stack trace for symbols you do not have access to, for this you need the pdbs without the private symbols stripped.
For the microsoft symbols entering '.symfix;.reload' in WinDbg should fix that problem.
Secondly although you will not get a stack trace for 3rd party dlls you will for your own application dlls, you will need to make sure your pdbs with public symbols match the version used to generate the dump.
You could ask the customer to generate the user stack trace in gflags and reproduce the error or to send you the pdbs with full symbol information.
It is also possible to open the dump file in Visual studio:
You may find this approach more familiar but you will not have access to WinDbg tools but as this is a post mortem analysis you can open the dump in visual studio and WinDbg as you are not invasively debugging anyway.