关闭 .NET 2.0 应用程序时出现 dr watson 崩溃对话框
我们偶尔会在进程退出时收到 dr watson 崩溃对话框。 该流程是.NET 2.0。 这 对话框不是很有帮助。 它说该过程停止工作并且详细信息 我可以看到它是关于 System.NullReferenceException 的，很好，但是回溯在哪里？
通常，当 .net 进程出现错误时，会按照标准打印回溯 错误。 但在本例中并非如此，可能是因为进程正在退出。 谁能给我 当此对话框出现时，有关如何获取有关崩溃原因的更多信息的指针 出现了？
We occasionally get a dr watson crash dialog on process exit. The process is .NET 2.0. The
dialog is not very helpful. It says that the process stopped working and in the details
I can see that it was about System.NullReferenceException, great but where is the traceback?
Normally when there is an error in .net process a traceback is printed to the standard
error. But not in this case, probably because of the process exiting. Could anyone give me
pointers on how to get more information about the cause of the crash when this dialog has
appeared?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我倾向于在开发计算机上禁用 Dr Watson 并使用 Visual Studio 作为唯一的解决方案当应用程序崩溃时，它会启动调试器。 我发现这种方法在根本原因分析方面更有用，特别是如果您有可用的调试信息。
I tend to disable Dr Watson on dev machines and use Visual Studio as the just it time debugger that gets fired up when an application bombs. I find this way more useful in terms of root cause analysis, particularly if you have debugging information available.
使用 WinDBG 附加。 异常很可能是在非托管代码中引发的。
Attach using WinDBG. In all likelihood the exception is being raised in un-managed code.
如果崩溃是可重现的，则可能值得在关闭应用程序之前将调试器设置为中断所有异常（可能是本机异常和 CLR）。 通常，崩溃可能是由于较早的错误造成的，因此这可能会给您提供线索。
您查看过 Dr Watson 转储文件吗？ 这些通常应该至少告诉您哪个模块导致了问题。 如果您正在处理本机代码，您将能够将 Dr Watson 提供的小型转储文件加载到 Visual Studio 中，并且提供该计算机上的调试符号文件和源代码，您将能够在以下位置查看应用程序的状态：崩溃的时间、有问题的线程的调用堆栈以及导致崩溃的代码行。 我不知道托管代码会发生什么，但可能值得尝试。
此链接应该为您提供有关分析小型转储文件的更多信息
CodeProject 链接
If the crash is reproducible, it might be worth setting the debugger to break on all exceptions (perhaps both native and CLR) before you shut down the application. Often a crash can be due to an earlier error so this might give you a clue.
Have you looked into the Dr Watson dump files? These should normally tell you at least which module has caused the problem. If you were dealing with native code you would be able to load the minidump file provided by Dr Watson into Visual Studio, and providing you have debug symbol files and source code on that machine you'd be able to see the state of your application at the time of the crash, call stack of the offending thread, and line of code that was causing the crash. I have no idea what happens with managed code, but it might be worth trying out.
This link should give you some more information about analysing minidump files
Link to CodeProject
我使用 DILE 来调试生产服务器上的应用程序。
它多次挽救了我的生命，因为应用程序崩溃了并且没有更多信息可用。 尽管它的学习曲线较高，但对于无法访问 Visual Studio 或其他工具的情况，值得了解。
我相信较新的版本也可以读取转储文件。
I use DILE to debug applications on production servers.
It has saved my life multiple times where applications would crash and no more information was available. It has a high learning curve though, but worth knowing about for those situations where you don't have access to Visual Studio or other tools.
I believe the newer versions can also read dump files.