C# 如何调试死锁？

How to debug a deadlock?

提问by Matthew Scharley

Other than that I don't know if I can reproduce it now that it's happened (I've been using this particular application for a week or two now without issue), assuming that I'm running my application in the VS debugger, how should I go about debugging a deadlock after it's happened? I thought I might be able to get at call stacks if I paused the program and hence see where the different threads were when it happened, but clicking pause just threw Visual Studio into a deadlock too till I killed my application.

除此之外，我不知道我现在是否可以重现它（我已经使用这个特定的应用程序一两个星期没有问题），假设我在 VS 调试器中运行我的应用程序，如何死锁发生后我应该去调试它吗？我认为如果我暂停程序，我可能能够进入调用堆栈，从而查看不同线程发生时的位置，但是单击暂停也会使 Visual Studio 陷入僵局，直到我杀死我的应用程序。

Is there some way other than browsing through my source tree to find potential problems? Is there a way to get at the call stacks once the problem has occured to see where the problem is? Any other tools/tips/tricks that might help?

除了浏览我的源代码树以查找潜在问题之外，还有其他方法吗？一旦出现问题，有没有办法访问调用堆栈以查看问题出在哪里？任何其他可能有帮助的工具/提示/技巧？

采纳答案by chris166

What you did was the correct way. If Visual Studio also deadlocks, that happens now and then. It's just bad luck, unless there's some other issue.

你做的是正确的方法。如果 Visual Studio 也出现死锁，那会不时发生。除非有其他问题，否则这只是运气不好。

You don't have to run the application in the debugger in order to debug it. Run the application normally, and if the deadlock happens, you can attach VS later. Ctrl+Alt+P, select the process, choose debugger type and click attach. Using a different set of debugger types might reduce the risk of VS crashing (especially if you don't debug native code)

您不必在调试器中运行应用程序来调试它。正常运行应用，如果出现死锁，可以稍后附加VS。Ctrl+Alt+P，选择进程，选择调试器类型并点击attach。使用一组不同的调试器类型可能会降低 VS 崩溃的风险（特别是如果您不调试本机代码）

A deadlock involves 2 or more threads. You probably know the first one (probably your UI thread) since you noticed the deadlock in your application. Now you only need to find the other one. With knowledge of the architecture, it should be easy to find (e.g. what other threads use the same locks, interact with the UI etc)

死锁涉及 2 个或更多线程。您可能知道第一个（可能是您的 UI 线程），因为您注意到应用程序中的死锁。现在你只需要找到另一个。了解架构后，应该很容易找到（例如，哪些其他线程使用相同的锁、与 UI 交互等）

If VS doesn't work at all, you can always use windbg. Download here: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

如果VS不工作在所有的，你总是可以使用的WinDbg。在此处下载：http: //www.microsoft.com/whdc/devtools/debugging/default.mspx

回答by Mikhail Churbanov

You can use different programs like Intel(R) Parallel Inspector:
http://software.intel.com/en-us/intel-parallel-inspector/

您可以使用不同的程序，如 Intel(R) Parallel Inspector：http:
//software.intel.com/en-us/intel-parallel-inspector/

Such programs can show you places in your code with potential deadlocks. However you should pay for it, or use it only evaluation period. Don't know if there is any free tools like this.

此类程序可以向您显示代码中存在潜在死锁的位置。但是，您应该为此付费，或者仅在评估期内使用它。不知道有没有这样的免费工具。

回答by Mikhail Churbanov

I'd try different approaches in the following order:

我会按以下顺序尝试不同的方法：

• First, inspect the code to look for thread-safety violations, making sure that your critical regions don't call other functions that will in turn try to lock a critical region.

• Use whatever tool you can get your hands on to visualize thread activity, I use an in-house perl script that parses an OS log we made and graphs all the context switches and shows when a thread gets pre-empted.

• If you can't find a good tool, do some logging to see the last threads that were running before the deadlock occurred. This will give you a clue as to where the issue might be caused, it helps if the locking mechanisms have unique names, like if an object has it's own thread, create a dedicated semaphore or mutex just to manage that thread.

• 首先，检查代码以查找线程安全违规，确保您的关键区域不会调用其他函数，而这些函数会反过来尝试锁定关键区域。

• 使用您可以使用的任何工具来可视化线程活动，我使用内部 perl 脚本来解析我们制作的操作系统日志并绘制所有上下文切换的图形并显示线程何时被抢占。

• 如果找不到好的工具，请执行一些日志记录以查看在发生死锁之前运行的最后一个线程。这将为您提供可能导致问题的线索，如果锁定机制具有唯一名称（例如，如果对象具有自己的线程），则创建专用信号量或互斥锁来管理该线程，这会有所帮助。

I hope this helps. Good luck!

我希望这有帮助。祝你好运！

回答by Oleg Zhylin

Just like anywhere, there're no "Silver bullet" tools to catch all the deadlocks. It is all about the sequence in which different threads aquire resources so your job is to find out where the order was violated. Usually Visual Studio or other debugger will provide stack traces and you will be able to find out where the discrepancy is. DevPartner Studio does provide deadlock analysis but last time I've checked there were too many false positives. Some static analysis tools will find some potential deadlocks too.

就像任何地方一样，没有“银弹”工具可以解决所有僵局。这完全取决于不同线程获取资源的顺序，因此您的工作是找出违反顺序的位置。通常 Visual Studio 或其他调试器会提供堆栈跟踪，您将能够找出差异所在。DevPartner Studio 确实提供了死锁分析，但上次我检查过有太多误报。一些静态分析工具也会发现一些潜在的死锁。

Other than that it helps to get the architecture straight to enforce resource aquisition order. For example, layering helps to make sure upper level locks are taken before lower ones but beware of callbacks.

除此之外，它有助于让架构直接执行资源获取顺序。例如，分层有助于确保在较低级别之前获取较高级别的锁，但要注意回调。