DLL远程注入成功后调用AllocConsole控制台不显示是什么原因

你遇到的问题是两个典型的DLL开发错误叠加导致的：

• 在DllMain中执行违规操作，触发Loader Lock风险
  DLL通过LoadLibraryA被加载到目标进程时，整个进程会持有Windows加载器全局锁（Loader Lock），此时DllMain的DLL_PROCESS_ATTACH分支代码完全运行在锁保护范围内。微软官方明确要求DllMain中只能调用极少量不依赖其他模块加载、不会触发锁竞争的kernel32基础API，禁止在其中创建线程、调用IO相关API、调用C运行时函数。
  你在DllMain中直接CreateThread启动的工作线程，会和加载器锁产生竞争：AllocConsole、freopen_s这类控制台相关API内部会隐式加载依赖模块、尝试获取加载器锁，非常容易出现静默调用失败、死锁的情况。这也是为什么替换成MessageBox可以正常弹出——MessageBox属于简单的user32弹窗调用，不会触发加载器锁竞争，也不依赖C运行时IO初始化，所以可以正常执行。
• 控制台初始化与流重定向逻辑不完整
  即使AllocConsole调用成功，你只重定向了stdout的C文件流，既没有重定向stdin、stderr，也没有处理C++ iostream流和C文件流的同步问题，同时输出字符串时没有加换行、没有强制刷新缓冲区，即使流绑定成功，内容也会留在缓冲区里不会输出到控制台。另外如果目标进程本身已经关联了其他控制台，AllocConsole会直接调用失败，你没有做返回值校验根本感知不到错误。

1. 禁止在DllMain中编写复杂逻辑，DLL_PROCESS_ATTACH分支只做最基础的模块句柄保存操作，不要直接创建工作线程。你可以给DLL导出一个专门的初始化函数，等DLL加载完成（也就是注入器中WaitForSingleObject等待LoadLibrary远程线程返回后），再通过CreateRemoteThread直接调用这个导出的初始化函数，此时已经完全退出Loader Lock范围，所有API都可以正常调用。
2. 修正控制台初始化代码，增加错误校验，完整重定向标准流：

// 放在导出的初始化函数、或者完全脱离DllMain上下文的工作线程中执行
if (!AllocConsole()) {
    DWORD err = GetLastError();
    // 可以用弹窗输出err排查具体错误，比如已经存在控制台、权限不足等
    return;
}
FILE* fp = nullptr;
freopen_s(&fp, "CONIN$", "r", stdin);
freopen_s(&fp, "CONOUT$", "w", stdout);
freopen_s(&fp, "CONOUT$", "w", stderr);
// 同步C++ iostream和C标准流
std::ios::sync_with_stdio(true);
// 测试输出加换行强制刷新缓冲区
printf("ttt\n");
std::cout << "cout test: ttt" << std::endl;
// 后续再做等待输入、逻辑执行、卸载DLL的操作

3. 调试阶段可以在每个API调用后加GetLastError错误校验，不要等现象不对再排查，尤其是AllocConsole、freopen_s这类容易静默失败的调用。

内容的提问来源于stack exchange，提问作者felipebubu