WinDbg 的 PRIMARY_PROBLEM_CLASS STACKIMMUNE 是什么意思？
一般来说，我找不到 !analyze -v 命令的 WinDbg 输出中不同字段可以包含的值的含义列表。
搜索很困难，因为命令的输出经常在没有明确解决字段值（例如 DEFAULT_BUCKET_ID 和 PRIMARY_PROBLEM_CLASS 的字段值）的情况下发布。有参考清单吗？
更具体地说：在内存转储分析期间，!analyze -v 命令的输出表明 DEFAULT_BUCKET_ID 和 PRIMARY_PROBLEM_CLASS 均为“STACKIMMUNE”。这意味着什么？
In general I cannot find a listing of the meaning of the values that the different fields in WinDbg's output of the !analyze -v command can contain.
Searching is difficult due to the fact that the output of the command is often posted without the field values (like that of DEFAULT_BUCKET_ID and PRIMARY_PROBLEM_CLASS) explicitly being addressed. Is there a reference list?
To be more specific: During the analysis of a memory dump, the output of the !analyze -v command indicated that both DEFAULT_BUCKET_ID and PRIMARY_PROBLEM_CLASS are "STACKIMMUNE". What does this mean?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先简单介绍一下
!analyze的工作原理。当
!analyze尝试确定访问冲突的原因时（以及一些其他类型的异常，例如 SEH 异常、C++ 异常、整数溢出、除以零等），它会查看引发异常的线程的调用堆栈并找出最上面的内容线程。然而，并非所有堆栈帧都有用。例如，对于 C++ 异常，您将在堆栈顶部看到
kernel32!RaiseException和your_module!__ except_handler3。必须跳过这些帧，因为它们不太可能是问题的原因。有时!analyze必须跳过很多帧才能到达感兴趣的帧。只需查看其他堆栈溢出问题的示例，其中有问题的代码低于约 40 帧。回答您的问题：
STACKIMMUNE表示调用堆栈中的所有帧都被跳过。当堆栈损坏或符号错误并使用!reload /i忽略任何不匹配错误时，可能会发生这种情况，并且可能在许多其他情况下发生。First a small introduction to how
!analyzeworks.When
!analyzetries to determine the reason for an access violation (and some other types of exceptions, for example, SEH exceptions, C++ exceptions, integer overflow, division by zero, etc.), it looks at the call stack of the thread that threw the exception and figures out what is on the top of the thread. However, not all stack frames are useful.For example, for C++ exceptions you will see
kernel32!RaiseExceptionandyour_module!__except_handler3at the top of the stack. Those frames must be skipped, because they are very unlikely the cause of the problem. Sometimes!analyzehas to skip lots of frames to get to the interesting frame. Just look at an example on other Stack Overflow question, where the offending code is ~40 frames below.To answer your question:
STACKIMMUNEis an indication that all frames in the call stack are skipped. This could happen when the stack is corrupted or when you have wrong symbols and used!reload /ito ignore any mismatch errors, and probably in many other cases.