预期LdrDoDebuggerBreak（），获得NtWaitForWorkViaWorkerFactory（）

Question

在调试研讨会期间，其中一位参与者无法效仿。

在Windows 10计算机上运行WinDbg 10.0.15603.137下的可执行文件时，调试器第一次在NtWaitForWorkViaWorkerFactory()而不是LdrDoDebuggerBreak()中的初始断点处断开。

尝试使用g运行可执行文件时，它表示没有可以运行的debugee。问题可能是什么？

这就是它的样子：

该应用程序的源代码很简单：

#include "stdafx.h"
#include <exception>

int _tmain(int /*argc*/, _TCHAR* /*argv*/[])
{
    throw std::exception();
}

注意：我几乎无法提供额外的信息，因为我无法再访问客户的PC，而且不会发生在我的PC上。

Answer 1

不能确定问题是什么，但我们可以说可能的问题。幸运的是，你问的是什么。

我无法为此分配确切的概率，但很可能隐式链接的DLL无法加载。这是在初始断点 ¹ 之前发生的主要事情。

为什么DLL无法加载？也许是某种资源问题，但是 - 特别是假设你试过运行一个＆＃34;新鲜＆＃34;重启后的机器 - 更有可能是在有问题的机器上加载额外的DLL。也许一个AVRF DLL，也许是一个AppInit DLL，可能是其他一种将DLL注入不知情和不愿意进程的方法之一 ² 。

正如我在评论中所说，找出肯定的方法是让WinDBG在创建进程时而不是在初始断点上中断，然后从那里开始调试。

执行此操作的方法是使用-xe cpr启动NTSD / CDB，在WinDBG的事件过滤器窗口中设置此项（可通过 Debug 菜单），或者在WinDBG中使用sxe cpr和.restart，假设你在WinDBG中启动了这个过程（而不是附加到它），这是我认为最好的简单，但是那个＆＃39品味问题。

¹ 我认为主要模块的TLS回调也是在初始断点之前执行的，但是有人在项目配置或CRT LIB中添加有问题的TLS回调的可能性有多大？ （隐式链接的DLL的TLS回调包含在＆＃34; DLL加载＆＃34 ;.）

² 但同样，更加邪恶和聪明的伎俩不太常见，因此不太可能。