问题标签 [threadabortexception]

下载文件后我必须执行更多代码，但它没有发生。编译器命中ClearControls();after DownloadFile();，但该函数未执行。在页面上，我收到打开或保存文件的提示。但是文本框没有被清除。在这种情况下应该怎么做。

我需要在服务引用中调用一个名为 CancelTransactionByRefPos 的方法。此方法具有以下签名：

如果此方法返回“0”，则取消成功。如果此方法返回另一个值，则必须再次调用该方法。

我编写了一个调用 CancelTransactionByRefPos 的 Cancel 方法。调用异步发生非常重要，因为它可能需要 30 秒才能给出响应。

我的方法看起来像：

当我取消注释中的 task.Wait() 部分时，我得到一个 ThreadAbortException。

当我取消对 task.Wait() 的注释并再次执行时，一切都运行良好，但是如果我必须等到我的任务执行完毕，那么异步调用该方法是没有用的。

编辑

我还配置了服务引用，因此它允许生成异步操作。同样的问题。

有谁知道调用 Thread.Abort 时不会执行 finally 语句的原因？我有这样的线程函数：

我使用 Thread.Abort 终止了这个线程。我在输出中看到的只是一堆等待，但没有其他行。我的主线程在调用 Thread.Abort 后继续运行（即子线程有足够的时间完成）。Debug.Log 函数是线程安全的。

这发生在 Windows 上。我正在使用 Mono（Unity 游戏引擎）。在 Mac 上它工作正常。在 iOS 上，我得到了这种行为，但它似乎取决于设备/iOS 版本或 XCode 版本（我还没有弄清楚）。在 Windows 上，它每次都会发生。

顺便说一句：在 iOS 上，如果我将另一个try {} catch {}放入 finally 语句，它会崩溃。

有谁知道为什么会这样？它似乎与 Thread.Abort 和 ThreadAbortException 的文档所说的完全不同。

我们有一个 IIS 托管的 WCF 服务，它接收大量数据以进行处理。该服务启动几个工作线程，然后返回离开工作线程以完成工作（这可能需要一个小时）。如果 WCF 服务空闲足够长的时间，IIS 会回收应用程序池中止工作线程。这个问题已经通过让工作线程偶尔调用一个虚拟服务来让应用程序池保持活动状态而被规避。如果您认为整个设置是一个非常糟糕的主意，我完全同意（不是我的代码）。所以没必要评论。

问题是我们仍然偶尔会遇到 ThreadAbortException。有什么方法可以获取有关什么/谁启动线程中止的其他信息？我知道这不是我们的代码。

最近我开始收到带有以下堆栈跟踪的警报：

消息：线程被中止。

堆栈跟踪：在 System.Net.Connection.CompleteStartConnection（布尔异步，HttpWebRequest httpWebRequest）在 System.Net.Connection.CompleteStartRequest（布尔 onSubmitThread，HttpWebRequest 请求，TriState 需要重新连接）在 System.Net.Connection.SubmitRequest（HttpWebRequest 请求，布尔强制提交) 在 System.Net.HttpWebRequest.SubmitRequest(ServicePoint servicePoint) 在 System.Net.HttpWebRequest.GetResponse() 在 System.Net.ServicePoint.SubmitRequest(HttpWebRequest request, String connName) 在 删除以保护身份

在我看来，在与远程服务器建立实际连接之前，该线程已中止。真的吗？为什么会出现这样的情况——试图缩小问题的范围。

我尝试查找有关该System.Net.Connection.CompleteStartConnection方法的文档，但找不到任何东西。有任何想法吗？

更新：添加调用代码的结构以响应评论。

更新 2：此警报仅偶尔出现几分钟，然后消失。

更新 3：我还没有提供的一条重要信息 - 我在更新 1 中显示的代码被计时器上的任务调用。

运行 WCF 服务时出现奇怪的错误。运行时线程中止接收我搜索了许多解决方案，没有任何帮助我在下面发布我的错误。

我正在从网页调用 WCF 服务。WCF服务在for循环中执行存储过程，是否会导致线程中止？我什至尝试增加 httpruntime 执行超时web.config但没有成功。

我正在尝试卸载 AppDomain 并得到CannotUnloadAppDomainException.

MSDN 提到了可能引发此异常的 3 个原因：

1. 默认应用程序域，必须在应用程序的生命周期内保持加载。
2. 具有无法立即停止执行的正在运行线程的应用程序域。
3. 已卸载的应用程序域。

我的应用程序受到案例 2) 的影响。

它有一些后台线程——例如，我有一个搜索索引线程运行它自己的 Dispatcher。

据我所知，当我打电话时

然后受影响域中的所有线程都会得到一个ThreadAbortException.

理想情况下，这意味着所有线程都被“杀死”/停止，对吧？

除了以下两种情况：

• 当一个线程调用一些托管代码时 - 运气不好......
• 当线程在 finally 语句中执行某些代码时。

似乎我的应用程序是第一个（可能它在后台调用了一些非托管代码，这就是它没有停止的原因）

所以最大的问题是：如果 AppDomain 有多个线程，如何卸载它？

我只看到两个选项：

• 尝试中止我的线程，然后以某种方式重新检查线程的状态。如果它们被停止，那么我可以调用AppDomain.Unload- 它不应该引发异常。
• 另一种选择只是简单地调用AppDomain.Unload。可能它会抛出异常。然后我可以捕捉到这个异常并重试卸载。由于AppDomain.Unload尝试中止所有受影响的线程，因此可能重试几次就足够了。

两种解决方案都使用了一些重试机制，这似乎是骇人听闻的。

在 .NET 中没有更简单、更强大的方法吗？

As a result of investigating this question: Rethrowing exception in Task doesn't make the Task to go to faulted state, I noticed some very odd behavior with the ThreadAbortException that I can't make sense of.

Now, I know that ThreadAbortException is a very special kind of exception to begin with. And the documentation is pretty clear about that when it says:

ThreadAbortException is a special exception that can be caught, but it will automatically be raised again at the end of the catch block.

Scenario #1: Documented behavior.

As expected, the ThreadAbortException is rethrown automatically, resulting in the following output:

Scenario #2: Where it gets interesting is when I decide to throw a different exception in the catch block:

In this case, I assumed that, despite the throwing of the ApplicationException, that the ThreadAbortException would be rethrown anyways to ensure that the documented behavior was preserved. To my surprise, this is the output that resulted:

Did the ApplicationException actually replace and prevent the ThreadAbortException from being thrown?!?

Scenario #3: And finally, to make matters more interesting, I wrap my existing exception handling with one more try-catch layer:

Now I'm not too sure what to expect. Which exception will be caught in the outer catch block? Will it be ApplicationException? And if so, does that mean that I'll be able to swallow the exception and actually manage to print out the will never be reached string after all?

This is the actual output:

From the above output, it looks like the outer catch block does actually catch an ApplicationException. But by the end of that catch block, the ThreadAbortException now all of a sudden reappears out of thin air and gets rethrown?

Question(s): Can someone explain and reconcile scenarios #2 and #3? How is it that in scenario #2, it looks as though the ThreadAbortException is, unexpectedly, replaced by a different exception? Yet, in scenario #3, it looks like ThreadAbortException was still there all along? How is this happening? Is this behavior documented somewhere?

将我的开发计算机升级到 Windows 10 后，我的 ASP.NET 应用程序已开始在任何时候调用 Response.End 或 Response.Redirect 时发出 ThreadAbortException。

我从研究中了解到这是预期的，您可以调用其他不会引发错误的函数。但是，在升级到 Windows 10 之前，我从来没有处理过这个错误。以前我使用 .NET 4.52 运行 Windows 8.1，而 Windows 10 现在是 .NET 4.6，所以我认为这与它有关。所以问题是为什么它刚刚开始抛出异常，有没有办法让它停止而不转换我的代码。

我将所有现有的 Web 应用程序从 Windows 2003 服务器（32 位）IIS 6 移动到 Windows 2012 服务器（64 位）IIS 8。.NET 2.0 到 .NET 4.0。我想将应用程序池保持在集成模式。迁移后我修复了许多其他问题。调用 Response.Redirect 时，我仍然会收到 ThreadAbortException。我知道将 endResponse 设置为 false 会解决。无法想象在所有页面中都这样做。有没有更简单的方法来做到这一点。也许配置文件中有一些东西。