处理 .NET 中的粗鲁应用程序中止
我知道我问这个问题是在向我敞开心扉，但我想我会看看 StackOverflow 是否有任何解决方案来解决我遇到的问题...
我有一个 C# 应用程序在客户端站点失败以一种我无法在本地重现的方式。不幸的是，对我来说很难（不可能）获得任何有助于隔离问题根源的信息。
我已经建立了一个相当广泛的错误监视框架，它正在监视所有常见位置中未处理的异常：
- 我控制的线程中的 Backstop 异常处理程序
- WinForms 异常的 Application.ThreadException
- AppDomain.CurrentDomain.UnhandledException
在我拥有的位置记录详细信息访问他们。
这在过去对于识别生产代码中的问题非常有用，但并没有为我提供有关当前一系列问题的任何信息。
我最好的猜测是，核心问题是“粗鲁”异常类型之一（线程中止、内存不足、堆栈溢出、访问冲突等），这些异常类型正在升级为粗鲁关闭，在我之前就破坏了进程。有机会看看发生了什么。
当我的进程崩溃时，我可以做些什么来快照信息，这将是有用的吗？理想情况下，我能够写出我的自定义日志格式，但如果我能有一种可靠的方法来确保将故障转储写入某处，我会很高兴。
我希望我可以实现从 CriticalFinalizerObject 派生的类，并让它在处理时吐出最后机会错误注销，但这似乎在我测试的 StackOverflow 场景中没有被触发。
由于缺少代码签名证书，我无法使用 Windows 错误报告和朋友。
我并不是试图从任意异常中“恢复”，我只是想记录下过程中出现的问题。
有什么想法吗？
I know I'm opening myself to a royal flaming by even asking this, but I thought I would see if StackOverflow has any solutions to a problem that I'm having...
I have a C# application that is failing at a client site in a way that I am unable to reproduce locally. Unfortunately, it is very difficult (impossible) for me to get any information that at all helps in isolating the source of the problem.
I have in place a rather extensive error monitoring framework which is watching for unhandled exceptions in all the usual places:
- Backstop exception handler in threads I control
- Application.ThreadException for WinForms exceptions
- AppDomain.CurrentDomain.UnhandledException
Which logs detailed information in a place where I have access to them.
This has been very useful in the past to identify issues in production code, but has not been giving me any information at about the current series of issues.
My best guess is that the core issue is one of the "rude" exception types (thread abort, out of memory, stack overflow, access violation, etc.) that are escalating to a rude shutdown that are ripping down the process before I have a chance to see what is going on.
Is there anything that I can be doing to snapshot information as my process is crashing that would be useful? Ideally, I would be able to write out my custom log format, but I would be happy if I could have a reliable way of ensuring that a crash dump is written somewhere.
I was hoping that I could implement class deriving from CriticalFinalizerObject and have it spit a last-chance error log out when it is disposing, but that doesn't seem to be triggered in the StackOverflow scenario which I tested.
I am unable to use Windows Error Reporting and friends due to the lack of a code signing certificate.
I'm not trying to "recover" from arbitrary exceptions, I'm just trying to make a note of what went wrong on the way down.
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以尝试创建 minidump 文件。这是一个 C++ API，但应该可以编写一个小型 C++ 程序，启动应用程序并保留进程句柄，等待进程句柄，然后在应用程序终止时使用进程句柄创建小型转储。
You could try creating a minidump file. This is a C++ API, but it should be possible to write a small C++ program that starts your application keeps a handle to the process, waits on the process handle, and then uses the process handle to create a minidump when the application dies.
如果您已完成您声称的操作：
那么您可能会捕获异常除非，也许它是由第三方或 COM 组件。
你肯定没有提供足够的信息。
我只是说，除非您发布大量更多信息，否则没有人可以为您提供任何有用的建议，即使这样我们也可能只能推测您问题的根源。
以全新的眼光审视您的代码。
有些错误无法通过日志记录捕获。
有关更多详细信息，请参阅此类似问题：
StackOverflowException in .NET
这是解释异步异常的链接（以及为什么无法从中恢复）：
http: //www.bluebytesoftware.com/blog/PermaLink.aspx?guid=c1898a31-a0aa-40af-871c-7847d98f1641
If you have done what you claim:
Then you would have caught the exception except perhaps if it is being thrown by a third party or COM component.
You certainly haven't given enough information.
I'm just saying that no-one can offer you any helpful advice unless you post a heck of lot more information and even at that we probably can only speculate as to the source of you problem.
Have a set of fresh eyes look at your code.
Some errors cannot be caught by logging.
See this similar question for more details:
StackOverflowException in .NET
Here's a link explaining asynchronous exceptions (and why you can't recover from them):
http://www.bluebytesoftware.com/blog/PermaLink.aspx?guid=c1898a31-a0aa-40af-871c-7847d98f1641