这确实看起来很“怪”但其实这背后的原理非常精妙展现了 WindowsWoW64Windows on Windows 64-bit机制的一个底层特性。之所以你的GetCmd64函数能够“通杀” 32 位和 64 位进程是因为在 64 位系统上每个 32 位进程其实也拥有一个隐藏的 64 位 PEB。1. 核心原因双重 PEB 结构在 64 位 Windows 系统中为了让 32 位程序能运行系统为 32 位进程创建了两套环境32 位 PEB (WoW64 PEB)这是 32 位程序自己能看到的用来处理正常的 32 位逻辑。64 位 PEB (Native PEB)这是系统内核用来管理该进程的。无论进程是 32 位还是 64 位内核都会为其分配一个 64 位的 PEB 结构。当你调用NtWow64QueryInformationProcess64时你绕过了 32 位的伪装直接去向系统索要那个64 位的基准信息。2. 为什么偏移量0x20, 0x70通用因为你使用的是NtWow64...系列函数你实际上是在以64 位观察者的视角来看待内存对于 64 位进程你读的是它唯一的 PEB偏移量自然是0x20和0x70。对于 32 位进程你读的是它隐藏的那个 64 位 PEB。在这个 64 位 PEB 里ProcessParameters的位置和 64 位进程一模一样也在0x20。所以你的代码通过一套 64 位的逻辑成功兼容了两类进程。3. 内存结构示意图4. 这种“全能”方式的优缺点优点缺点 / 风险代码统一不需要写两套逻辑32位套和64位套。依赖未公开 APINtWow64...系列属于未公开函数虽然稳定但理论上微软有权修改。绕过重定向能看到进程最原始的内核信息。地址计算复杂在 VB6 里必须用Currency处理 8 字节偏移写错一个小数点如0.0032就直接崩溃。跨架构读取作为 32 位程序这是读取 64 位数据的唯一可靠 API 途径。权限要求依然需要PROCESS_QUERY_INFORMATION和PROCESS_VM_READ权限。5. 补充一个小细节NtWow64ReadVirtualMemory64 hProc, cmd64.Buffer, buf(0), cmd64.Length / 10000, 0这里能成功是因为buf(0)是字节数组的首地址而cmd64.BufferCurrency正好存放了远程进程的 64 位内存地址。VB6 的这种“黑科技”处理方式恰好利用了Currency的 8 字节特性完美模拟了 64 位指针。总结你的发现非常敏锐这正是 WoW64 架构下最强大的读取技巧——统一使用 64 位视角。既然系统为所有进程都准备了 64 位 PEB那我们只读 64 位 PEB 确实就能搞定一切。