xperf 调用堆栈跟踪，特定于 dll
我在使用 xperf 跟踪获取完整调用堆栈时遇到了一些问题。这是在 Win7 64 位电脑上。在更高的层面上，我有一个加载多个 dll 的 exe，它们也完成了大部分工作。所有 pdb 文件都位于一个目录中，并且我在可执行代码中获得有效的符号和调用堆栈，因此我非常确定我的符号路径设置正确。
一旦我的 exe 调用其中一个已加载的 dll，我就会丢失调用堆栈信息，并且堆栈列显示 plugin_name.dll!?，当展开时，它会调用自身。权重选项卡显示高百分比 (50-90%) 和高计数，但我无法获得堆栈的任何实际函数调用。例如：
Process, Stack, Module, Function, Weight, % Weight, Count, TimeStamp
, | kernel32.dll!BaseThreadInitThunk, , , 59067.075556, 73.29, 59075,
, | |- plugin_name.dll!?, , , 45036.186642, 55.88, 45042,
, | | plugin_name.dll!?, , , 45036.186642, 55.88, 45042,
基于这些，
http://blogs.msdn.com/b/pigscanfly/archive/2009/08/06/stack-walking-in-xperf.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ff191014(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/ff191014.aspx
这似乎表明 xperf
- “...不知道该地址处有什么可执行映像”
- “...超出了最大堆栈深度” 。
我发现的可能原因是 FPO（帧指针优化）已打开（我已使用 /Oy- 明确禁用它们，即使它们不应该打开），或者超出了最大堆栈深度，我不知道如何确定这是否是我所击中的。
由于无法查看 dll 中的时间花费在哪里，我无法获得非常有用的信息，因此我想弄清楚发生了什么。
有人对阅读或尝试的内容有什么建议吗？我缺少的 stackwalk 是否有任何限制？是否有针对 dll 中的调用堆栈的特殊符号设置？
I'm running into some problems getting full call stacks with my xperf traces. This is on a Win7 64bit pc. At a higher level, I have an exe that loads several dlls, which also do the bulk of the work. All pdb files are in a single directory, and I get valid symbols and call stacks in executable code, so I'm pretty sure my symbol path is setup correctly.
As soon as my exe calls into one of the loaded dlls, I lose the call stack information and the stack column displays plugin_name.dll!? which, when expanded, calls into itself. The weight tab shows a high percentage (50-90%) and a high count, but I'm unable to get any actual function calls for the stack. For example:
Process, Stack, Module, Function, Weight, % Weight, Count, TimeStamp
, | kernel32.dll!BaseThreadInitThunk, , , 59067.075556, 73.29, 59075,
, | |- plugin_name.dll!?, , , 45036.186642, 55.88, 45042,
, | | plugin_name.dll!?, , , 45036.186642, 55.88, 45042,
Based on these,
http://blogs.msdn.com/b/pigscanfly/archive/2009/08/06/stack-walking-in-xperf.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ff191014(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/ff191014.aspx
this seems to indicate that xperf
- "...doesn’t know what executable image was at the address"
- "...Maximum stack depth is exceeded".
The possible causes for this that I've found are either the FPO (frame pointer optimizations) is turned on (I've explicitly disabled with /Oy- even though they shouldn't be on), or the max stack depth is exceeded, which I'm not sure how to determine if this is what I'm hitting or not.
Without being able to see where time is being spent in the dlls, I'm not able to get very much useful information, so I'd like to figure out what is going on.
Does anyone have any recommendations for things to read or try? Are there any limitations with stackwalk that I'm missing? Is there any special setup for symbols, specific to call stacks in dlls?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
大多数符号加载问题是由于调试引擎和符号服务器库不匹配而发生的。
安装包含 Windows 性能套件的最新 sdk 并从同一目录运行 wpa/xperf 应该可以解决符号加载问题。我假设符号服务器路径是正确的。使用 procexp.exe 查看 dbghelp.dll 和 symsrv.dll 版本，并使用路径查看 xperf 或目录中的任何工具指出上述 dll 的最新可用或发布版本。
谢谢，
苏尚特B
Mostly symbol loading issue is occurred due to mismatched debug engine and symbol server libraries.
Do install latest sdk containing windows performance kit and running wpa/xperf from same directory should resolve the symbol loading issue. i 'm assuming symbol server path is correct. Use procexp.exe to see dbghelp.dll and symsrv.dll version and path to see xperf or any tool from directory is pointing out to latest available or shipped version of above mentioned dlls.
Thanks,
SushantB
请尝试此处< /a>:
禁用分页执行程序
为了使跟踪在 64 位 Windows 上工作，您需要设置 DisablePagingExecutive 注册表项。这告诉操作系统不要将内核模式驱动程序和系统代码分页到磁盘，这是使用 xperf 获取 64 位调用堆栈的先决条件，因为 64 位堆栈遍历取决于可执行映像中的元数据，并且在某些情况下不允许 xperf 堆栈遍历代码触摸调出页面。从提升的命令提示符运行以下命令将为您设置此注册表项。
设置此注册表项后，您需要重新启动系统才能记录调用堆栈。设置此标志意味着 Windows 内核将更多页面锁定到 RAM 中，因此这可能会消耗大约 10 MB 的额外物理内存。
Try the following, from here:
Disable Paging Executive
In order for tracing to work on 64-bit Windows you need to set the DisablePagingExecutive registry key. This tells the operating system not to page kernel mode drivers and system code to disk, which is a prerequisite for getting 64-bit call stacks using xperf, because 64-bit stack walking depends on metadata in the executable images, and in some situations the xperf stack walk code is not allowed to touch paged out pages. Running the following command from an elevated command prompt will set this registry key for you.
After setting this registry key you will need to reboot your system before you can record call stacks. Having this flag set means that the Windows kernel locks more pages into RAM, so this will probably consume about 10 MB of additional physical memory.
创建一个新的环境变量DBGHELP，将其设置为1。现在创建一个环境变量 DBGHELP_LOG 并将其设置为日志文件，例如 D:\DbgHelpLog.txt。符号加载完成后，关闭 xperfview/wpa 并查看日志为什么符号加载失败。
诊断 DBGHELP 符号加载
http://blogs.msdn.com/b/matt_pietrek/archive/2005/04/12/407721.aspx
create a new envvar DBGHELP, set it to 1. Now create a the envvar DBGHELP_LOG and set it to a log file like D:\DbgHelpLog.txt. After symbol loading is finished, close xperfview/wpa and look into the log why symbol loading failed.
Diagnosing DBGHELP symbol loading
http://blogs.msdn.com/b/matt_pietrek/archive/2005/04/12/407721.aspx