DLL内部线程未正确关闭，除联系厂商外如何自行处理？

先给你一个明确的结论：强烈不建议手动强制关闭第三方DLL的内部线程，风险实在太高，具体原因和可行的替代方案我给你拆解下：

为什么不能手动关线程？ #

• 强制终止线程（比如用Thread.Abort()或者通过ProcessThread操作）会导致不可控的资源泄漏：DLL可能握着未释放的文件句柄、内存锁、数据库连接，甚至破坏进程内的共享状态，搞不好整个应用都会崩掉或者出现诡异的问题。
• 你根本不知道这些线程在后台干啥——要是它正在写文件或者更新数据库，中途被打断，直接就会造成数据损坏，这锅你可背不起。

可行的替代方案 #

1. 用进程隔离彻底规避风险 #

把调用这个DLL的逻辑单独放到一个子进程里，别和主进程混在一起。当需要清理的时候，直接终止整个子进程就行：

• 系统会自动回收子进程的所有资源，包括DLL的那些顽固线程，完全不会影响主进程的稳定性。
• 实现起来也不难：写个轻量的控制台程序专门处理DLL调用，主进程通过命名管道、WCF或者简单的命令行参数和它通信，用完就杀掉子进程。

2. 再仔细检查调用规范 #

有没有可能是你调用Close/Dispose的姿势不对？比如DLL还有异步任务在跑，你就急着关了？

• 翻一遍供应商给的文档，确认调用顺序——有些DLL要求必须先结束所有异步操作、释放所有关联资源，才能调用销毁方法。
• 试试多调用一次Close/Dispose？虽然听起来离谱，但有些垃圾DLL的实现就是这么糙，多触发一次说不定就彻底清理了。

3. 临时应急：捕获异常忽略（仅限迫不得已） #

如果那个ThreadAbortException只是后台蹦出来，没影响功能，你可以在调用Dispose的时候把它捕获了：

try
{
    yourDllInstance.Dispose();
}
catch (ThreadAbortException ex)
{
    // 记个日志就行，别慌，DLL大概率已经自己吞了这个异常
    Log.Warn($"DLL内部线程抛了ThreadAbortException，但方法返回正常: {ex.Message}");
}

这只是权宜之计，治标不治本，还是得催厂商修。

关于你尝试的ProcessThreadCollection #

别碰！就算你识别出了那些线程，也绝对不能强制终止它们。一来你不知道线程在执行什么关键操作，二来.NET里ProcessThread.Abort()已经被标记为过时，很多场景下根本没用，反而会搞出更多问题。

总的来说，最靠谱的还是催厂商修复DLL的线程清理逻辑；短期救急的话，优先用进程隔离的方式，别去碰人家DLL的内部线程。

内容的提问来源于stack exchange，提问作者evilfish