我明白你的痛点——用CreateRemoteThread注入会创建新线程，导致目标进程崩溃，而你需要让DLL逻辑跑在目标的主线程里。咱们一步步拆解问题，找到可行的方案：

为什么CreateRemoteThread不行？ #

CreateRemoteThread的核心就是在目标进程里新建一个线程来加载你的DLL（通过调用LoadLibrary），如果你的DLL里有必须依赖主线程才能执行的逻辑（比如操作GUI控件、访问主线程专属资源、调用线程绑定的API），那在新线程里执行这些代码必然会导致崩溃。

可行的解决方案 #

方案1：修改目标主线程的上下文，强制它加载DLL #

这个方法的思路是“劫持”目标主线程：让它暂停当前执行的代码，先去加载你的DLL，然后再回到原来的逻辑继续执行。步骤如下：

• 获取目标进程的主线程ID：可以通过C#的Process.GetProcessById获取进程，然后遍历它的Threads集合找到主线程（通常是ID最小的那个，也可以通过GetMainThreadId这类原生API）。
• 挂起主线程：调用SuspendThread API暂停主线程执行。
• 在目标进程分配内存：用VirtualAllocEx分配一块可读写的内存，写入你的DLL路径（注意匹配ANSI/Unicode，对应LoadLibraryA或LoadLibraryW）。
• 获取并保存主线程的上下文：调用GetThreadContext，拿到当前的指令指针（x86是EIP，x64是RIP）和栈指针等信息，一定要保存好这些值，后续需要恢复。
• 修改主线程上下文：把指令指针改成目标进程中LoadLibrary的地址（kernel32.dll的LoadLibrary地址在所有进程中是共享的，直接用GetProcAddress获取即可），然后调整栈指针，把DLL路径的内存地址作为参数压入栈（符合stdcall调用约定）。
• 恢复主线程执行：调用SetThreadContext写入修改后的上下文，再调用ResumeThread让主线程继续——这时候主线程会先执行LoadLibrary加载你的DLL。
• 还原主线程原有逻辑：在你的DLL的DllMain里，当DLL_PROCESS_ATTACH触发时，记录下之前保存的原指令指针，等核心逻辑执行完后，再次修改上下文让主线程跳回原来的指令位置，否则目标进程会因为原逻辑中断而崩溃。

方案2：先注入DLL，再让主线程触发核心逻辑 #

如果修改线程上下文太复杂，你可以换个思路：先用CreateRemoteThread把DLL注入进程（此时DLL在新线程的DllMain里只做最小化初始化），再让主线程执行核心逻辑：

• 注入DLL后，在DllMain的DLL_PROCESS_ATTACH分支里，只做简单初始化（比如注册一个自定义消息、创建一个事件），绝对不要执行可能导致崩溃的逻辑。
• 如果目标是GUI进程，找到它的主窗口句柄，用PostMessage发送自定义消息，目标窗口的消息处理函数会在主线程执行，你可以在DLL里挂钩这个消息处理函数，或让消息触发核心逻辑。
• 如果是控制台进程，可以在DLL里等待主线程的信号（比如事件），再通过钩子类API（如SetWindowsHookEx）让主线程触发你的代码。

排查问题：是DLL还是注入器的锅？ #

你可以做个简单测试定位问题：

• 写一个极简的测试DLL，DllMain里只调用OutputDebugString输出一条日志，别的什么都不做。
• 用CreateRemoteThread注入这个测试DLL到目标进程，如果进程崩溃，大概率是注入器的问题（比如权限不够、进程架构不匹配——x86注入x64进程会崩溃）；如果不崩溃，那就是原DLL里有必须在主线程执行的代码，需要把这些代码移到主线程触发执行。

关键注意事项 #

• DllMain只做简单操作：微软明确建议DllMain只做初始化/清理，不要调用可能导致线程阻塞、加载其他DLL、操作GUI的API，这些逻辑放到主线程执行才安全。
• 架构必须匹配：你的C#注入器、C++ DLL、目标进程必须是同一架构（都是x86或都是x64），否则注入会失败或崩溃。
• 权限要足够：注入器需要以管理员身份运行，且目标进程没有开启特殊保护机制（比如ASLR、DEP，或是受保护的系统进程）。

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