我有一个我正在追逐的错误（我认为它是一个僵局）。当我运行代码时它挂起而没有调试器标记错误，所以过了一会儿我尝试按下暂停（全部中断）按钮。然后调试器报告“进程似乎已死锁......”。然后我可以看到所有的线程都被保持在EnterCriticalSection的行上，除了那个已经在临界区内的线程。当我使用调试器查看C.S.内部的线程时，我看到一个绿色箭头，伴随着一个指向GetWindowText线的小蓝圈......如下所示：
// stuff A
{
GetWindowText(editwin[a].child_window_handle,existing_text,MAX_TEXT_SIZE-1);
}
// stuff B
如果我将鼠标悬停在绿色箭头上，我会看到文本“这是当该线程从当前函数返回时执行的下一个语句”。现在这让我很难过，因为我不知道它是否意味着它被卡在“东西A”中并等待回来或者卡在GetWindowText里面并且不知何故卡在里面。 GetWindowText的参数对我来说都很合理。如果我点击“进入”，我会收到消息“无法步骤。该过程已被软破坏”。
编辑：东西A实际上是声明：
if (buf_ptr != NULL)
答案 0 :(得分：6)
通常，代码行旁边的绿色箭头表示“这是下一行将被执行，如果不是因为我们被困在更深的堆栈帧中。”但是，根据目前提供的信息，VS无法肯定地说......
[编辑 - 当然，对Win32的深入了解可以提供一个非常好的猜测 - 根据GetWindowText（）API已知的陷阱，查看“mos”的答案可能的解释]
如前所述，Visual Studio向您展示的内容有时会产生误导。为了更准确地了解正在发生的事情，您需要关闭VS默认启用的一些无用的“功能”。在工具中 - ＆gt;选项 - ＆gt;调试 - ＆gt;一般，请确保：
这应该允许你：
1）中断/跳过导致死锁的确切指令
2）无论模块是什么，都要查看到那一点的完整堆栈跟踪
，请在可用时查看源代码答案 1 :(得分：5)
你的问题是GetWindowText实际上是向另一个窗口发送一条消息并等待它返回。如果该窗口由另一个等待临界区的线程拥有，则GetWindowText将永远等待。
你被困在GetWindowText中，并造成了死锁。
答案 2 :(得分：4)
正如之前的回复所示，您的代码被困在“Stuff A”中。
我可以为您的工具带推荐另一种工具吗？
我通常发现使用WinDbg调试本机同步问题要容易得多。 只需在WinDbg中启动您的程序，指向正确的符号，所有信息都将在那里使用！locks，！cs和k命令进行调查。
如果您是WinDbg的新用户，您会发现互联网已经充满了有关它的信息。我建议您也阅读Advanced Windows Debugging。
与用户友好的VS调试器相比，它有点难以启动，但是每学习一分钟，您将学习如何使用它将为您节省数小时的调试时间。
答案 3 :(得分：0)
假设你的问题是“这是否正常”，那么是的，调试器通常会在关键部分停留之后显示该语句。