从 ProcessThread 到托管线程
我们经常会在生产环境中遇到 Windows 服务关闭的问题，但我们无法重现。可能要过几个月才会再次发生这种情况。
我正在进行一些诊断来尝试帮助解决该问题，我正在考虑的一件事是在我们启动应用程序关闭后 60 秒内向系统线程池添加一个事件。我们的应用程序应该最多在 10 秒内完全关闭。
在这种情况下，我想在事件日志中跟踪进程剩余的正在运行的线程。
我可以使用 System.Diagnostics.Process.GetCurrentProcess.Threads 获取正在运行的线程。这些线程对象具有本机 Win32 线程 ID 等。
我想知道是否有任何方法可以从这些线程 ID 返回到它们在当前进程中表示的任何托管线程。 我尝试这样做的原因是因为对于我们的线程池和我们生成的其他线程，我们给出了代表其用途的名称，这确实有助于恢复它们。
Periodically we get a hang on shut down of a Windows service in a production environment that we just cannot reproduce. It can be months before it happens again.
I'm putting in some diagnostics to try and help with the issue, one thing I'm looking at is adding an event to the system thread pool for 60 seconds after we initiate shut down of the application. Our application should shutdown cleanly within 10 seconds maximium.
In this event I would like to trace out the remaining running threads of the process to the event log.
I can get the running threads using System.Diagnostics.Process.GetCurrentProcess.Threads. These threads objects have native Win32 thread id's etc.
I was wondering if there was any way of getting back from these thread id's to any managed threads that they represent in the current process.
The reason I am trying to do this is because for our thread pools and other threads we spawn we give the names which represent their purpose and it would really help to get these back.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于以下原因这是不可能的。 引自 MSDN：
因此，托管线程和操作系统线程之间不存在一对一的映射。
那么现在的问题就变成了，如何获取当前进程中当前运行的所有托管线程的列表？不幸的是我不知道答案。
This is impossible for the following reason. Quote from MSDN:
So there's no one-to-one mapping between managed threads and OS threads.
So now the question becomes, how to get a list of all the managed threads currently running in the current process? Unfortunately I don't know the answer.
看起来这是不可能的。
幸运的是，我们有自己的线程库，它包装了 .NET 库，并且我能够添加功能来保留可用于这些诊断的活动线程列表。
这工作得很好，但当然需要付出相当多的努力和测试，但希望我们能弄清楚它的真相。
It does not look like this is possible.
Luckily for us we have our own threading libraries which wrap the .NET libraries and I was able to put in functionality to keep a list of active threads that we can use for these diagnostics.
This works quite well but there was a fair bit of effort involved and testing of course, but hopefully we'll get o the bottom of it.