诊断生产.NET桌面程序中的应用程序挂起

我有麻烦了。我正在开发的应用程序的用户之一偶尔但有规律地遇到应用程序挂起的情况。

发生这种情况时，我们会在计算机的事件日志中找到一个带有“应用程序挂起”源的条目，并提供提示性消息“挂起应用程序[我的应用程序]，版本[正确的版本]，挂起模块hungapp，版本0.0.0.0，挂起地址0x00000000。”

我正在记录应用程序引发的所有未处理的异常，并且在发生这种情况时，日志文件中没有任何条目。

我目前的工作假设是，在应用程序调用不安全的旧版API时会发生这种挂起。这不会令我惊讶。我已经使用此API多年了，虽然我之前从未见过它挂起过，但它确实是糟糕的代码。此外，用户报告该程序似乎在随机时间挂起。我认为这不是真的。不是我不相信她，而是与旧版API对话的代码在由BackgroundWorker调用的方法中运行。如果后台线程使应用程序挂起，那么用户可能会觉得它像随机发生的那样。

因此，我有两个问题，一个是具体问题，一个是一般问题。

具体问题是：我希望如果在非UI线程上运行的方法挂起，它将杀死该线程。实际上会杀死整个应用程序吗？

一般问题：

我已经在记录所有未处理的异常。我的程序已经设置为使用跟踪（尽管我将需要添加工具代码来跟踪可疑方法中的活动）。还有其他我应该做的事情吗？.NET应用程序挂起时，是否有诊断工具可以进行某种崩溃后分析？我可以调用.NET框架内的机制来捕获更多（和更多可用的）数据吗？

编辑： 在仔细检查我的代码时，我记得它对BackgroundWorker的所有使用都是通过我实现的实用程序类实现的，该实用程序类包装了在异常处理程序中调用的方法。该处理程序记录该异常，然后将其作为实用程序对象的所有权返回。UI线程中的完成事件处理程序重新引发了异常（不理想，因为我丢失了调用堆栈，但已经记录了该异常），导致UI的主要异常处理程序将异常报告给消息框，然后终止该异常。应用程式。

由于这一切都没有发生，因此我非常有信心在后台线程中不会引发任何异常。好吧，无论如何，.NET没有例外。

进一步跟进：

幸运的是，我现在已经从用户那里获得了足够的数据，以确保不会在旧版API中发生死机。这显然是我做错的事情，这意味着我可以解决问题，所以赢了。这也意味着我可以通过跟踪来隔离问题，这是另一个胜利。我对这个问题的答案感到非常高兴；我更高兴我可能不需要这个问题。

另外：PostSharp非常出色。如果需要在现有应用程序中添加检测代码，则几乎可以肯定应该使用它。