• 如何分析 WindowsDump:Dump 起源与初始设置


    https://www.qcloud.com/community/article/511817

    转者注:让我感觉以前看蓝屏都白看了~~~原来蓝屏也可以分析具体原因。

    适用场景:Windows 系列系统异常宕机(蓝屏)且存在Dump文件(*.dmp)

    相关背景解释:众所周知,Windows历史上BUG比较多,无故宕机、程序卡死的例子较多,为了避免无迹象可循的情况,Microsoft 推出 Dump机制在宕机时先进行蓝屏收集宕机前状态,并且可以捕获到导致异常的关键错误,当Windows出现异常Crash时Windows会调用Dump系统来形成一个转储文件(*.dmp),通过特殊工具可以进行分析。

    如何确保有Dump文件?

    1、 要清楚,Dump文件是Windows启动的一个保险机制,而蓝屏主要是用做给系统争取时间进行收集Dump文件所用,所以一个逻辑是必然会有的,那就是如果蓝屏必然触发Dump机制,Dump机制会根据系统设置进行Mini或Full的收集。

    2、 关于Dump文件的大小,如果Dump设置的存放位置不满足Dump文件大小也是不会产生Dump文件:

    a) MiniDump文件大小:取决于Windows 运行时内存页大小,比如当前CVM跑的是数据库,那么产生的Dump文件大小就是数据库交换内存的概要信息,比如说16G内存有20%被使用,宕机时所产生的Dump文件就是3.2g的概要信息(即涉及到的进程的大概地址)

    b) FullDump文件大小:取决于Windows物理内存大小,FullDump即完整收集模式,将整个系统在宕机时的整个内存运行态进行记录,通常该文件的大小是物理大小的1.0 ~ 1.5倍左右(倍数的浮动取决于虚拟内存交换设置的大小)

    3、 所以,要确保有Dump文件,最低条件是:

    a) 开启Windows系统的Dump

    b) 确保设置的位置剩余空间是物理内存1.5倍以上

    c) 若要完整的Dump日志进行分析,请选择完整收集模式

    注1:QCloud Windows Server 2008R2为避免磁盘风险,默认不开启FullDump模式,所以如果需要详细Debug文件,则手动开启即可:
    如果您想要启用完全内存转储选项,手动设置为 0x1 以下注册表子项下的CrashDumpEnabled注册表项并重新启动 Windows:
    HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCrashControl

    注2:也可以使用Memory Dump Configuration工具进行设置

    蓝屏文件俗称BSOD(Blue Screen Of Death),一般出现后处理方式就只有重启,蓝屏的产生原因是:

    BSOD有三大规则会触发:

    • 保护规则:当低级特权的代码直接访问高级特权代码与数据时(如某些安全防护软件通过用户态进行驱动修改)就会触发BSOD;
    • 异常处理:程序异常时程序本身没有写好完整的异常处理回路,系统接收到异常则启动先行中断机制,所以程序设计存在问题时也有可能触发蓝屏(比如之前0Day漏洞黑客所用的工具导致蓝屏,明显就是没有写好异常处理回路)
    • SDK、DDK中调用了只有在特定IRQL调用的内核参数,即只有特定CPU中断请求的时候才可以使用DDK调用的内核参数在未到中断请求时被发起调用(一般出现于.Net Winform应用中)

    在腾讯云主机上,一般第一、二规则导致的BSOD Case比较多。

    附蓝屏产生过程:

    转储原理:

    一、 BSOD分析:

    虽然BSOD必然会输出Dump文件,但是BSOD也会带来相关有用的信息,一般BSOD呈现方式为:

    • 浅蓝框:序言、错误的信息描述
    • 中间部分:建议的措施
    • 红色框:相关中断的代码及其参数

    关于 浅蓝框 跟 中间部分 基本可以忽略,作为排错需要关注的下面红色框的参数,下面具体举个例子:

    *STOP:0x0000007F(0xc0000005,0x808945CF,0xF78A6A88,0XF78A6784)

    0x0000007F:7F,即导致BSOD的关键代码,通常可以在https://support.microsoft.com/zh-cn/search 可以搜索到
    0xc0000005:5,涉及的进程对象(Process Object)
    0x808945CF:对应对象的指针(指向位置)
    0xF78A6A88:进程涉及的映像名
    0XF78A6784:备注解析信息等

    二、Dump文件分析

    1、 WinDbg工具环境准备,配置好symbol 路径,使其用相关Debug命令时可以自动加载对应module(Minidump可能信息提供较少):

    2、 设置Path路径为SRVD:sysmbolshttp://msdl.microsoft.com/download/symbols 使其在加载相关module(最常见就是NT)时自动从mircosoft 进行下载

    Eg:Open Crash Dump时自动加载涉及到的Module:

    对应文件夹出现相关Modeule:

    3、 打开*.dmp文件:

    4、 初始界面如下:

    5、 点击!analyze –v 可以进行自动分析,可以看到这个Dump是因为底层调用netkvm.sys导致crash:

    6、 但是大部分Crash并不是如例子所示就可以明确看出涉及的驱动进程,所以可以使用!process [0,0]查看crash时hang住的进程:

    7、 通过!thread 可以到进程中涉及的线程信息(可以看到这里是Idel时系统Crash掉):

    8、 如果是系统组件导致的问题的,可以通过lm kv 导出加载的内核模块:

    9、 !vm 可以看出crash时内存状态(可以看到用户的 175ptServer.exe 进程占用较高):

    10、 当然也可以通过memory视图来定位thread hang在什么位置:

    11、 WinDbg提供大量其他视图可以辅助定位原因,可以根据实际case进行灵活使用(比如Disassembly视图也是很好用的一个功能):

    后言

    Windows系统方面的 MiniDump提供信息较少,FullDump在Memory这块信息会比较多,具体使用方法需要根据具体Case来灵活调整使用。

    附常见命令:

    (1)进程: !process [0 0];dt nt!_eprocess;dt nt!_kprocess;
    (2)线程: !thread;dt nt!_ethread;dt nt!_kthread;
    (3)I/O请求包: dt nt!_irp;!irpfind;
    (4)常见同步对象:lkd> dt nt!_kevent;lkd> dt nt!_kmutant;lkd> dt nt!_ksemaphore;
    (5)作业:lkd> !job;会话(lkd> !session);内存管理(lkd> !vm)的命令等。

    附件是WinDbg使用指南(English版)

  • 相关阅读:
    [Swift]LeetCode773. 滑动谜题 | Sliding Puzzle
    [Swift]LeetCode771. 宝石与石头 | Jewels and Stones
    [Swift]LeetCode770. 基本计算器 IV | Basic Calculator IV
    [Swift]LeetCode769. 最多能完成排序的块 | Max Chunks To Make Sorted
    [Swift]LeetCode768. 最多能完成排序的块 II | Max Chunks To Make Sorted II
    转 玩转Bash变量
    转 shell脚本学习指南
    转: 两个 Shell 网站: explainshell 和 shellcheck
    转 BAT CMD 批处理文件脚本总结(中文)
    转 windows 下 Oracle 导出表结构
  • 原文地址:https://www.cnblogs.com/tcicy/p/8076382.html
Copyright © 2020-2023  润新知