Process Explorer 中的有限堆栈跟踪
我有一个在 Windows Server 2003 SP2 下运行的进程。当我想检查其中一个线程的堆栈跟踪时，它始终限制为 9 个条目。这些条目已正确解析（我已就位 PDB），但列表只是在中间切开。
您知道 Process Explorer 有什么限制吗？
I have a process running under Windows Server 2003 SP2. When I want to check stack trace of one of its threads it is always limited to 9 entries. Those entries are resolved correctly (I have PDBs in place) but list is just cut in middle.
Do you know of any limitation in Process Explorer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我假设您认为该线程的完整堆栈跟踪应该有超过 9 个条目。您没有提到是 32 位操作系统还是 64 位操作系统，但我会假设 32 位操作系统，然后作为事后考虑讨论 64 位操作系统。
有时，在 32 位系统上收集堆栈跟踪时，您无法收集堆栈跟踪的任何项目，或者即使您知道调用堆栈更深，也只能收集有限数量的堆栈帧信息。原因是：
不同的调用约定将数据放在堆栈上的不同位置，从而导致遍历堆栈变得困难。我能想到 4 个定义，其中 3 个是常用的，还有一个比较奇特的：cdecl、fastcall、stdcall、naked。
对于发布版本，代码优化器可以使用称为帧指针省略（FPO）的技术来消除帧指针。如果没有 FPO（有时，即使 PDB 文件中包含 FPO 数据），您也无法成功遍历调用堆栈。
钩子 - 任何辅助 DLL、防病毒、调试钩子、检测代码、恶意软件等都可能在某个时候弄乱调用堆栈，因为它们在调用堆栈上插入了自己的存根代码，并且该小部分可能无法步行 钩子 - 任何辅助 DLL、防病毒、调试钩子、检测代码、恶意软件等，都可能在某个时候弄乱调用堆栈，因为它们在调用堆栈上插入了自己的存根代码，
字节码虚拟机。根据虚拟机的编写方式，VM 可能会在调用堆栈上放置蹦床以帮助其执行。这些将使堆栈难以成功行走。
由于 32 位 Windows 上的调用约定多种多样（来自 Microsoft 和其他供应商），因此很难弄清楚当您从一个框架移动到另一个框架时会发生什么。
对于 64 位系统，指定了一种调用约定。这让生活变得更加轻松。也就是说，您仍然会遇到帮助程序 DLL 和挂钩在堆栈上执行自己的操作的问题，并且这仍然可能会在遍历堆栈时给您带来问题。
我怀疑 Process Explorer 是否存在限制。我认为问题在于，由于我上面列出的原因之一，遍历该线程的调用堆栈是有问题的。
I am assuming that you think the complete stack trace for this thread should have more than 9 entries. You don't mention if 32 bit OS or 64 bit OS, but I will assume 32 bit OS and then cover 64 bit as an afterthought.
Sometimes when collecting a stack trace on 32 bit systems you cannot collect any items for the stack trace or you can only collect a limited amount of stack frame information even though you know the callstack is deeper. The reasons for this are:
Different calling conventions put data in different places on the stack, making it hard to walk the stack. I can think of 4 definitions, 3 in common use, one more exotic: cdecl, fastcall, stdcall, naked.
For release builds, the code optimizer may do away with the frame pointers using a technique known as Frame Pointer Omission (FPO). Without the FPO (and sometimes, even with the FPO data in a PDB file) you cannot successfully walk the callstack.
Hooks - any helper DLLs, anti-virus, debugging hooks, instrumented code, malware, etc, may mess up the callstack at somepoint because they've inserted their own stub code on the callstack and that small section may not be walkable by the stack walker.
Bytecode virtual machines. Depending upon how the virtual machine is written, the VM may place trampolines on the callstack to aid its execution. These will make the stack hard to walk successfully.
Because of the variety of calling conventions on 32 bit Windows (from both Microsoft and other vendors) it is hard to work out what to expect when you move from one frame to another.
For 64 bit systems there is one calling convention specified. That makes life a lot easier. That said, you still have the issues of helper DLLs and hooks doing their own thing with the stack and that may still cause you problems when walking the stack.
I doubt there is a limitation in Process Explorer. I think the issue is just that walking the callstack for that thread is problematic because of one of the reasons I've listed above.