<p>内存映射文件不能直接用于进程注入，仅适用于跨进程共享数据或零拷贝读取；C# 不适合传统 DLL 远程注入，因依赖 CLR 且缺乏安全稳定的纯托管注入机制，应改用 IPC 或动态编译方案。</p>
内存映射文件本身不能直接用于进程注入
这是最关键的判断：C# 的 MemoryMappedFile 类只是对 Windows 内存映射机制的托管封装，它不提供执行权、不绕过 DEP/CFG、也不具备向目标进程写入可执行代码并触发执行的能力。你用它写入数据，目标进程读得见；但想让它“跑起来”，必须配合其他机制（比如远程线程、APC 注入、SetThreadContext 等），而这些在 .NET 中没有安全、稳定、无需 P/Invoke 的纯托管实现。
常见错误现象：MemoryMappedFile.CreateOrOpen 成功了，目标进程也 MemoryMappedFile.OpenExisting 成功了，但写进去的 shellcode 一动不动——因为没人调用它。
使用场景仅限于：跨进程共享结构化数据（如配置块、状态标志、日志缓冲区）、大文件零拷贝读取。不是代码注入通道。
为什么 C# 不适合做传统意义上的 DLL 远程注入
.NET 程序默认运行在 CLR 上，目标进程若非 .NET 进程（比如 notepad.exe、chrome.exe），你无法直接 LoadLibrary 一个 .NET DLL；即使目标是 .NET 进程，.NET 5+ 默认禁用 Assembly.LoadFrom 远程路径，且 Assembly 加载需满足加载上下文、依赖解析、信任级别等约束，远比 native DLL 复杂得多。
容易踩的坑：
- 试图用
VirtualAllocEx+WriteProcessMemory+CreateRemoteThread注入 C# 编译出的 DLL —— 它依赖 mscoree.dll 和特定运行时，目标进程大概率崩溃或静默失败 - 把 C# 编译成 /clr:pure 或使用 C++/CLI 包装 —— 已被弃用，VS 2022 不再支持，且仍受限于目标进程是否加载了对应版本的 CLR
- 忽略目标进程架构（x86/x64/ARM64）匹配 ——
OpenProcess成功不代表后续操作能走通，WriteProcessMemory会因指针截断直接失败
如果真要共享代码逻辑，该怎么做
真正可行的路径是“分离关注点”：把业务逻辑抽成独立、无依赖、纯计算的 .NET Standard 类库，然后通过进程间通信（IPC）驱动它，而不是强行注入。
实操建议：
- 用
NamedPipeServerStream+NamedPipeClientStream做低延迟 IPC，服务端在目标进程内常驻，客户端在你的控制进程发指令 - 用
MemoryMappedFile共享输入/输出缓冲区（比如一个struct的固定大小区域），再用命名事件（EventWaitHandle）通知就绪 —— 避免轮询 - 若必须动态加载逻辑，改用源码编译方案：目标进程内置 Roslyn 编译器（
Microsoft.CodeAnalysis.CSharp），接收 C# 源字符串，编译为AssemblyLoadContext中的动态程序集 —— 仅适用于你完全可控的目标进程
性能影响：命名管道在本地开销极低（微秒级）；内存映射文件共享结构体比序列化 JSON 快 10 倍以上，但要注意 MemoryMappedViewAccessor 的 Read/Write 是同步阻塞的，别在 UI 线程调。
绕不开 P/Invoke 时，哪些 Win32 函数必须小心
一旦决定走 native 注入路线（比如注入一个 x64 native DLL 到记事本），C# 就必须用 DllImport 调用底层 API，这时几个函数的参数和生命周期极易出错：
-
OpenProcess：必须带PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_CREATE_THREAD，缺一不可；返回值为IntPtr.Zero时，立刻查Marshal.GetLastWin32Error()，常见 5（拒绝访问）、299（只读内存） -
VirtualAllocEx：分配地址建议用IntPtr.Zero让系统选，flAllocationType一定要含MEM_COMMIT | MEM_RESERVE，flProtect若写 shellcode 必须是PAGE_EXECUTE_READWRITE（DEP 会拦截，需提前处理） -
CreateRemoteThread：第三个参数（起始地址）必须是目标进程中已加载模块里的函数（如kernel32.dll!LoadLibraryA），不能是你刚分配的内存地址——除非你手写机器码跳转 stub，且目标进程开了 DEP 例外
兼容性影响：Windows 10 1809+ 对 CreateRemoteThread 做了 ETW 日志增强，杀软几乎必报；QueueUserAPC 注入虽隐蔽，但要求目标线程处于 alertable wait 状态，实际成功率不稳定。
这事本身就很重——哪怕每步都写对，目标进程的反调试、AV/EDR 钩子、模块加载策略、SEH 链破坏，都可能让注入在第 5 步无声失败。别指望靠封装一个“Inject”方法就搞定。
