如何判断转储文件是在 32 位系统还是 64 位系统下生成的?

缘起

曾经在 2022 年分析过一个崩溃转储,文章在这里。在那个案例中,堆空间大小将近 4GB。根据上次的结论,这应该是一个运行在 64 位系统下的 32 位进程崩溃产生的转储文件。这让我有了一个疑问?怎么从进程转储文件中得知进程是 32 位的还是 64 位的?如果是 32 位进程,怎么判断是运行在 32 位系统上还是运行在 64 位系统上呢?

说明: 64 位进程只能运行在 64 位系统下,不能运行在 32 位系统下。如果进程是 64 位的,那么系统一定是 64 位的。

判断进程位数

判断进程是 32 位进程还是 64 位进程比较简单。通过很多地方都可以判断。

  1. 根据寄存器进行判断。

    运行在 32 位系统上的进程,并没有用到 gs 寄存器,gs 的值一般为 0

    如果 gs 的值不是 0,说明是 32 位进程运行在 64 位系统上或者是 64 位进程运行在 64 位系统上。

    具体是 32 位进程还是 64 位进程,可以通过 r 命令查看寄存器进行判断,如果是 32 位寄存器(Exx),说明是 32 位进程。如果是 64 位寄存器(Rxx),说明是 64 位进程。

  2. 使用 !dh 命令查看模块的文件头信息,如果显示了 14C machine (i386) 或者 characteristic 下显示了 32 bit word machine 说明是 32 位进程。如果显示了 8664 machine (X64) 说明是 64 位进程。

    说明: !dh 的输出很长,可以用如下命令过滤 .shell -ci "!dh -f module_name" findstr "machine"

c11efd89c890270d0d035547e8bb12fb.png
compare-32-64-bit-process
  1. 使用 lm 命令查看模块,如果模块中有 wow64cpu, wow64win, wow64 中的一个,说明是 32 位进程运行在 64 位系统下。

    如果不包含,或者是 32 位进程运行在 32 位系统上,或者是 64 位进程运行在 64 位系统上。具体是哪种情况,可以通过查看寄存器位数进行判断。

说明: 如果是 32 位进程运行在 64 位系统上, 45 有可能不准确。

判断系统位数

如果进程是 64 位的,其运行的系统一定是 64 位的。如果进程是 32 位的,其运行的系统可能是 32 位的,也可能是 64 位的。如果进程是 32 位的,有可能运行在 32 位系统上,也有可能运行在 64 位系统上。接下来只关心 32 位进程是否运行在 64 位系统上的情况。

  1. 通过 !peb 命令查看环境变量进行判断

    如果环境变量名包含 PROCESSOR_ARCHITEW6432,说明是 32 位进程运行在 64 系统上。

    如果环境变量名以 W6432 结尾(例如, CommonProgramW6432PROCESSOR_ARCHITEW6432ProgramW6432 等)或者名字中包含 (x86)(例如, CommonProgramFiles(x86)ProgramFiles(x86) 等)说明是 64 位系统。

  2. 通过 lm 查看模块进行判断

    如果包含 wow64, wow64cpu, wow64win, wowcon, wow64base  中的一个模块,说明是 32 位进程运行在 64 系统上。

  3. 通过 gs 寄存器判断

    运行在 32 位系统上的进程,并没有用到 gs 寄存器,gs 的值一般为 0。如果 gs 的值不是 0,说明 64 位系统。

  4. 通过 wow64exts 进行判断

    使用 .load wow64exts 加载模块,然后执行 !info 命令进程查看。如果 Guest (WoW) PEB: 或者  Guest (WoW) TEB: 不是 0,说明是 32 位进程运行在 64 位系统上。

你还知道哪些判断方法呢?欢迎分享。

参考资料

https://stackoverflow.com/questions/8084538/determine-if-process-dump-was-generated-on-x64-or-x86-machine

https://stackoverflow.com/questions/43308814/is-there-a-windbg-command-to-find-out-if-a-process-is-a-32-bit-one-or-a-64-bit-o

https://www.tessferrandez.com/blog/2010/09/29/capturing-memory-dumps-for-32-bit-processes-on-an-x64-machine.html

内容概要:本文详细介绍了“秒杀商城”微服务架构的设计与实战全过程,涵盖系统从需求分析、服务拆分、技术选型到核心功能开发、分布式事务处理、容器化部署及监控链路追踪的完整流程。重点解决了高并发场景下的超卖问题,采用Redis预减库存、消息队列削峰、数据库乐观锁等手段保障数据一致性,并通过Nacos实现服务注册发现与配置管理,利用Seata处理跨服务分布式事务,结合RabbitMQ实现异步下单,提升系统吞吐能力。同时,项目支持Docker Compose快速部署和Kubernetes生产级编排,集成Sleuth+Zipkin链路追踪与Prometheus+Grafana监控体系,构建可观测性强的微服务系统。; 适合人群:具备Java基础和Spring Boot开发经验,熟悉微服务基本概念的中高级研发人员,尤其是希望深入理解高并发系统设计、分布式事务、服务治理等核心技术的开发者;适合工作2-5年、有志于转型微服务或提升架构能力的工程师; 使用场景及目标:①学习如何基于Spring Cloud Alibaba构建完整的微服务项目;②掌握秒杀场景下高并发、超卖控制、异步化、削峰填谷等关键技术方案;③实践分布式事务(Seata)、服务熔断降级、链路追踪、统一配置中心等企业级中间件的应用;④完成从本地开发到容器化部署的全流程落地; 阅读建议:建议按照文档提供的七个阶段循序渐进地动手实践,重点关注秒杀流程设计、服务间通信机制、分布式事务实现和系统性能优化部分,结合代码调试与监控工具深入理解各组件协作原理,真正掌握高并发微服务系统的构建能力。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值