内部证据已锁定安全软件，客户为何仍要求微软背锅？

一次看似随机的跨应用崩溃，最终指向了安全软件将 64 位 hook 代码错误注入 32 位进程的兼容性缺陷。Raymond Chen 通过 crash dump、反汇编、内存权限与模块路径，层层还原了“零字节变成指令”的完整证据链。

本期深度解析不仅带你理解 x86/x64 指令解码、inline detour 与 WOW64 环境的调试关键，更关注技术真相揭晓后，如何跨越安全流程、供应商关系与责任归因的组织障碍。欢迎结合原文阅读，体验这场扎实而精彩的调试推理。

原文链接：

https://devblogs.microsoft.com/oldnewthing/20260925-00/?p=112731/

原文标题：Debugging walkthrough: Access violation on nonsense instruction, episode 3

主要内容：

• 多个无关程序出现相同崩溃，说明问题更可能来自具备跨进程影响力的共同组件。

• 所谓“荒谬指令”实为 CPU 将连续 `00` 字节解码为内存写操作，执行流误入填零区域便会触发 access violation。

• 函数入口的异常机器码揭示了一次失败的 inline detour：64 位跳转指令被放入 32 位执行环境。

• 同一串字节在 x64 下是正常的 `mov r10` 与 `jmp r10`，在 x86 下却被拆解成不同指令，最终落入零字节区域。

• 内存区域、权限变化与 DLL 路径共同锁定了安全软件注入组件；但根因确认后，修复仍受制于客户的安全验证与责任认定流程。

推荐理由：