在 WinDbg 中中断特定异常的最快方法？ .net 4.0 应用程序
各位，
使用 WinDbg 调试 .net 4.0 应用程序（我是 WinDbg 的初学者）。当我遇到堆栈溢出时，我试图中断： (NTSTATUS) 0xc00000fd – 无法创建堆栈的新保护页
不幸的是，这种溢出发生在长时间运行的进程大约 2 小时后，日志告诉我它并不总是在同一时间/地点发生。如果我附加到调试器中的进程，程序运行速度非常慢......可能需要几天的时间才能发现错误！有没有办法通过告诉 WinDbg 仅因此特定错误而中断来加速应用程序/WinDbg？
Folks,
Debugging a .net 4.0 app using WinDbg (I'm a beginner to WinDbg). I'm trying to break when I hit a stack overflow:
(NTSTATUS) 0xc00000fd – A new guard page for the stack cannot be created
Unfortunately, this overflow happens about 2-hours into a long-running process and logs tells me that it doesn't always happen at the same time/place. If I attach to the process in the debugger, the program runs terribly slow...it might take a few days to hit the bug! Is there a way to speed up the app/WinDbg by telling WinDbg to ONLY break for this particular error?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以指示 ADPLus 在发生异常时创建进程转储。 John Robbins 一篇关于该主题的好文章。然后，您可以使用 WinDbg 调试转储文件。
请注意，原始的 adplus.vbs 已被 adplus.exe 取代，它应该提供相同的功能。根据我的经验，新实现存在一些问题，因此您可能需要使用旧脚本，该脚本仍然以 adplus_old.vbs 形式提供。
You can instruct ADPLus to create dumps of the process when exceptions occur. John Robbins has a good article on the subject. You can then use WinDbg to debug the dump file(s).
Be aware, that the original adplus.vbs has been replaced by adplus.exe, which is supposed to provide the same functionality. In my experience there are a few problems with the new implementation, so you may need to use the old script, which is still available as adplus_old.vbs.
通常，附加调试器不会使应用程序减慢太多（与从调试器启动应用程序相比，调试器会将堆设置为调试模式）。
但默认情况下，调试器将跟踪事件（异常和 OutputDebugString），在您的情况下，可能有太多事件。连接调试器后，您可以禁用所有异常处理。 （菜单调试/事件过滤器，或命令 sxi）。您必须更改所有事件的处理（
sxi *表示未知事件，并不适用于所有事件）。您还可以使用.outmask-0xFFFFFFFF禁用所有跟踪。然后使用 sxe -c ".outmask /d" sov 仅启用堆栈溢出事件Usually, attaching a debugger would not slow down an application too much (compared to starting the application from the debugger, which will set the heap in debug mode).
But by default, the debugger will trace events (exceptions and OutputDebugString), and in your case, there may be too much of them. After attaching with the debugger, you can disable all exception handling. (Menu Debug/Event Filters, or command sxi). You have to change the handling for all events (
sxi *means unknown events, and does not apply to all events). You can also disable all tracing with.outmask-0xFFFFFFFF. Then enable only the stack overflow event withsxe -c ".outmask /d" sov