调试由于Win32生产过程中的死锁而导致的明显挂起的步骤和技术是什么？我听说WinDbg可以用于此目的，但是我们能否提供有关如何实现此目的的明确提示？

解决方案

我们正在使用哪种语言/ IDE？

在.Net中，我们可以查看应用程序的线程：Debug-> Windows-> Threads或者Ctrl + Alt + H

这篇文章应该使我们开始使用各种选项。

关于调试死锁的另一篇有用的文章。

调试死锁可能很棘手。我通常会进行某种日志记录，然后查看日志的停止位置。我使用OutputDebugString()登录到文件或者调试控制台。

如果我们可以访问源代码和内存转储(或者实时调试会话)，则调试真正的死锁实际上很容易。

我们要做的只是查看线程，找到正在某种共享资源上等待的线程(例如，在" WaitForSingleObject"中挂起等待)。通常，从那里确定是两个或者多个线程彼此锁定在一起，然后我们只需确定哪个线程打破了锁定层次结构就可以了。

如果我们不容易确定哪些线程被锁定，请使用本文中显示的方法来跟踪每个线程的锁链。进入循环时，循环中的线程是死锁的。

最好的办法是从添加日志记录语句开始。通常，我只会建议处于死锁状态的共享资源周围，但一般来说添加它们可能会指向我们不期望的情况或者代码区域。实际上，广为宣传的stackoverflow.com数据库问题实际上是log4net！ stackoverflow团队从未怀疑过log4net，只有通过检查日志记录(讽刺地)才能证明这一点。我最初会放弃任何复杂的工具，例如WinDgb，因为使用它们不是非常直观的恕我直言。

如果我们很懒惰，则可以安装Application Verifier，然后添加模块并从基本测试中仅选择"锁定"。
那么我们可以在任何调试器下运行应用程序。
如果关键部分出现死锁，我们将立即找到原因。