这种现象是这样的。
我试图实施dll注入。我的应用程序创建了暂停＆＃39; state，（使用带CREATE_SUSPENDED的CreateProcess），等待加载一个重要的dll（当然是kernel32.dll），然后执行注入。注入后使用ResumeThread恢复挂起的进程。
我正在使用挂起进程创建，希望在除dll加载之外的任何其他执行之前注入dll。但在执行此操作时，我发现了一些有趣的东西。
我只是使用notepad.exe测试了这次注射，它运行得很好。但是当我将可执行文件复制为notepad2.exe时，我的注入会等待无限时间。 Kernel32.dll永远不会加载，直到进程的主线程恢复。
似乎有某种经过验证的＆＃39;预先加载模块的可执行文件（或者我的计算机中安装了一些已经使用dll注入的安全解决方案可能会导致执行不同的操作）。
是否有人知道是否存在以不同方式加载模块的任何事情？ （坦率地说，我仍然不了解Windows进程的生命周期......）
答案 0 :(得分：0)
我想我找到了答案。答案是，尽管进程处于SUSPENDED状态，因此主线程已停止，当该进程中的某个线程尝试访问模块时，则会加载所需的模块（这意味着，Windows应用程序似乎 'Lazy Load'需要模块）
在评论中，我说由我的PC上安装的某些安全解决方案保护的进程使用Detour注入DLL，因此在进程处于SUSPENDED状态时加载某些Process中的模块。 但这不是Detour的具体案例，而是每个流程的一般问题。
我很愚蠢，我使用的注入技术是，列出目标进程中加载的所有模块，找到kernel32.dll，计算LoadLibraryW的偏移量，并使用远程线程调用该函数。在这种技术中，注入器枚举所有模块 BEFORE LoadLibrary函数被调用，因此LazyLoading永远不会发生，因此我永远不会在进程上看到kernel32.dll。
当我使用从当前进程使用GetProcAddress的简单技术时，获取LoadLibrary函数的地址，并远程调用该进程，kernel32.dll已成功加载并且注入成功。
如果通过'使用Detour的安全解决方案'保护了多个应用程序，即使我暂停了该过程，也会发生注入尝试，这就是为什么kernel32.dll被加载到notepad.exe（在列表中）安全解决方案），但没有加载到notepad2.exe（因为图像名称不同，它不在列表中）。
我只是愚蠢，试图使用更复杂的方法进行dll注入，这就是导致所有这些问题的原因。
非常感谢你的评论。