64位同架构进程调用CreateRemoteThread返回0xc00000005错误咨询

核心可能原因 #

• 进程保护机制拦截
  Windows Server 2016默认对核心系统服务启用了受保护进程（PP）/轻量级受保护进程（PPL）机制，即使持有Local System权限，常规的CreateRemoteThread调用也会被安全模块拦截，返回访问拒绝错误。32位环境下你测试的目标进程大概率未开启该保护，因此可以正常调用。你可以通过Process Explorer查看目标进程的Protection属性确认是否属于受保护进程。
• 错误码混淆问题
  你提到的错误码0xc00000005实际是STATUS_ACCESS_VIOLATION（内存访问违规），并非标准的访问拒绝错误码0xC0000022。如果该错误是远程线程启动后抛出的，而非CreateRemoteThread接口调用时直接返回，大概率是你传入的线程入口地址非法：比如硬编码了32位环境下的LoadLibrary地址、目标进程中申请的内存页没有可执行权限、传入的参数地址指向非法内存。
• 句柄权限实际未生效
  即使你在OpenProcess时传入了所需的权限标识，也需要先校验OpenProcess的返回值是否有效，调用GetLastError确认打开进程阶段没有报错。少数情况下如果目标进程自行修改了DACL，主动拒绝了当前令牌的PROCESS_CREATE_THREAD权限，即使是Local System身份也会拿到无对应权限的句柄。
• 参数适配错误
  64位环境下所有指针类型长度为8字节，如果你在代码中混用了32位变量存储64位地址（比如用DWORD类型存储内存地址、线程入口地址），会导致地址截断，调用时触发访问错误。

排查步骤 #

1. 先确认错误的触发时机：调用CreateRemoteThread后立刻调用GetLastError，如果返回值为5（ERROR_ACCESS_DENIED）属于接口调用被拒，优先排查进程保护、句柄权限问题；如果是线程执行后返回的0xc0000005，优先排查线程入口地址、参数合法性。
2. 验证OpenProcess拿到的句柄权限：可以调用GetKernelObjectSecurity检查句柄持有的实际权限，确认PROCESS_CREATE_THREAD权限已生效。
3. 检查所有地址相关变量的类型：确保所有存储内存地址、函数指针的变量使用UINT_PTR或者LPVOID等指针类型，不要使用固定长度的32位类型。
4. 如果目标进程确实开启了PP/PPL保护，常规方案无法直接调用CreateRemoteThread，建议通过其他官方支持的进程间通信方案替代远程线程注入。

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