蓝瓶的钙,好喝的钙——windows,我要蓝屏的

故障解除

自从用windows起,蓝屏已经习以为常了。
不过这次我的probook的蓝屏却令我郁闷了,为什么郁闷?在后面我会说。
情况是这样的:之前一直用着好好的系统。在关机之后再开机就直接蓝屏了。再重启,还是蓝屏。
可以确认的是,近期没有硬件的更改,也没有安装或者卸载软件(补丁除外)。
操作系统信息(可以通过系统自带的msinfo32获取):

OS Name Microsoft Windows 7 Professional
Version 6.1.7601 Service Pack 1 Build 7601
System Type x64-based PC
Windows Directory C:\Windows
System Directory C:\Windows\system32
Boot Device \Device\HarddiskVolume1
Installed Physical Memory (RAM) 6.00 GB
Total Virtual Memory 11.9 GB
Page File Space 5.96 GB
Page File F:\pagefile.sys

不过,关机之前的那段时间,我并不在笔记本旁边。关机操作我也是远程执行的。回来后再开机就蓝屏了。因此,在这之前,唯一有可能有安装更新的软件就是我安装的杀毒软件:Avast! .
不过我当时只是考虑过一下是小A引起的,但心里还是不太相信是小A所为。因此,首先进行的是其它的处理。

令我郁闷的并不是蓝屏,而是蓝屏了,却没有找到dump文件。换句话说,我笔记本的windows死了,我不知道它是怎么死的。没有dump文件,我完全不知道是哪个硬件、哪个驱动或者哪个服务引起的蓝屏。这也就是文章开头我所说的郁闷之处。

起先,安全模式还可以进入。
safe-mode-F8-windows-7

运行系统的事件查看器(event viewer ), 发现有好多服务无法启动了,而这些都是系统的核心服务,按理是不应该无法启动的。于是重启按F8,选择Last Known Good Configuration(最后一次正确配置),蓝屏依旧。检查了下磁盘,是OK的。运行chkdsk /F /R 对C: 、 D: 盘进行错误检测和修复,没有发现什么问题。检测完了之后重启,照样蓝屏。

蓝屏代码是 0x00000050 PAGE_FAULT_IN_NONPAGED_AREA
M$ 官方相关文档:
http://technet.microsoft.com/en-us/library/cc962944.aspx
Bug Check 0x50: PAGE_FAULT_IN_NONPAGED_AREA

如往常的情况一样,看windows官方的文档基本上没法解决蓝屏问题。
由于现在安全模式也没法进了。进安全模式时,在驱动加载到aswVmm.sys 等文件时,卡在那里不动了。这一看就是Avast!的驱动,这更加坚定了我把Avast!认定为此次蓝屏事件的“罪魁祸首”的想法。

于是,重启,进入ArchLinux (我笔记本装的是双系统), 然后进入
C:\Windows\System32\drivers
删除所有 asw*.sys 文件,这些个文件都是Avast!的驱动。
然后再进入Avast!的安装目录,把所有Avast!的文件连同安装目录一起删除。
再重启,熟悉的windows登录界面出来了。。。
果然是你——Avast!.


追根究底

问题已然解决,不过不应该就此打住。
windows死掉时,为什么“没有”产生dump文件?这个问题依旧不明。
于是再次用神一样的Google找到了答案。

windows可以产生三种不同的dump文件:
完全内存dump
内核内存dump
迷你内存dump(64KB)

Windows can generate any one of the following memory dump file types:

Complete memory dump
Kernel memory dump
Small memory dump (64 KB)

而通常系统产生的是Small memory dump (64 KB),其位置默认在
C:\Windows\Minidump

而此次蓝屏我却没有在这里找到任何dump文件。为什么?
这跟和dump文件产生相关的启动配置有关。
windows的dump文件产生存在一定的规则,这些规则包括:
对于Complete memory dump:
If a second problem occurs and another complete memory dump (or kernel memory dump) file is created, the previous file is overwritten.

对于Kernel memory dump:
If a second problem occurs and another kernel memory dump file (or a complete memory dump file) is created, the previous file is overwritten when the 'Overwrite any existing file' setting is checked.

对于Small memory dump:
If a second problem occurs and a second small memory dump file is created, the previous file is preserved. Each additional file is given a distinct name. The date is encoded in the file name. For example, Mini022900-01.dmp is the first memory dump generated on February 29, 2000. A list of all small memory dump files is kept in the %SystemRoot%\Minidump folder.

详情见: http://support.microsoft.com/kb/254649

由此可见:
Complete memory dump在蓝屏再次发生时会被无条件覆盖掉,而Kernel memory dump是否被覆盖要看配置( HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl分支下的Overwrite值是否为1,为1值覆盖。 ),Small memory dump则总是被保留。

于是我看了下我的win 7 的配置:
System-failure-config
我这里勾选了“自动重启”,也就是说,蓝屏之后,马上会重启,根本没时间去看蓝屏代码了。那么我是怎么看到蓝屏代码的?开机时按F8,然后选择 Disable automatic restart on system failure 选项启动,就可以无视那个自动重启配置了。

然后,我看到,我这里配置的dump类型居然是Kernel memory dump ,记得默认应该是Small memory dump (64 KB)的。
既然是Kernel memory dump ,为什么在%SystemRoot% (C:\Windows)下面没有看到 MEMORY.DMP 文件?
原因是 memory.dmp 文件的存储/删除算法。其算法如下:

a. 首先把内核错误报告给Online Crash Analysis Service.
b. 然后,如果机器注册表中 AlwaysKeepMemoryDump 项的值被设置为 1, 那么将dump文件存储在磁盘。
c. 否则, 如果机器上的操作系统是Windows Server SKU, 那么将dump文件存储在磁盘。
d. 再则, 如此这台机器加入了windows域 (如一些大公司的工作站会有域服务器,工作站可以加入某个域), 那么将dump文件存储在磁盘。
e. 否则, 如果机器不属于某个域(而是属于某个workgroup,通常家用电脑是这样),那么就进行如下判断:
如果磁盘空闲容量 >= 25GB, 那么将dump文件存储在磁盘。
否则 (磁盘空闲容量 < 25 GB), 删除dump文件.

windows-dump-file-store-delete-algorithm

很明显,我这里的情况是AlwaysKeepMemoryDump值为0.
即使到害最后一种,也无法保留dump文件。。。看了下,我的C盘的剩余容量只有12.7GB了。
好了,现在解释了为什么dump文件没有在我的电脑上保存下来。

AlwaysKeepMemoryDump 的确切位置是:

1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl ! AlwaysKeepMemoryDump Type: REG_DWORD.

修改成Small memory dump ,然后把那个自动重启也给去掉。以备防止以后crash系统能保存dump文件。

====================================================

Small memory dump (64 KB) 文件的保存策略:
kernel minidumps 文件默认保存在 %SystemRoot%\Minidump 目录下。
而这个位置值也是在注册表 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl 分支下的。键名为 MinidumpDir .
kernel minidumps 文件的保存策略相对来说比较简单。它是根据以下注册表项来决定是否保存dump文件到磁盘的:

1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl ! MinidumpsCount Type: REG_DWORD, default value is 50

minidump分析工具


bluescreenview


由nirsoft出品的一个小工具。很实用。
BlueScreenView scans all your minidump files created during 'blue screen of death' crashes, and displays the information about all crashes in one table. For each crash, BlueScreenView displays the minidump filename, the date/time of the crash, the basic crash information displayed in the blue screen (Bug Check Code and 4 parameters), and the details of the driver or module that possibly caused the crash (filename, product name, file description, and file version).
For each crash displayed in the upper pane, you can view the details of the device drivers loaded during the crash in the lower pane. BlueScreenView also mark the drivers that their addresses found in the crash stack, so you can easily locate the suspected drivers that possibly caused the crash.
bluescreenview

bluescreenview2

=====================================================

Minilyzer

这是一个利用windows调试工具分析dump文件的Windows shell脚本文件。
它还支持分析 Full memory dumps (C:\Windows\Memory.dmp) 。

Minilyzer is a Windows shell script that uses Microsoft’s Debugging Tools for Windows to analyze the Minidump files that are created when a BSOD occurs and generate a report detailing the event. Full memory dumps (C:\Windows\Memory.dmp) can also be analyzed.

下载:
http://patrickmylund.com/projects/minilyzer/
github地址:
https://github.com/pmylund/minilyzer
minilyzer_screenshot


参考文档

http://support.microsoft.com/kb/254649

Kernel-Mode Dump Files

Kernel dump storage and clean up behavior in Windows 7

SKU:
SKU是一个通用零售的专业词汇,是英文Stock-Keeping Unit 的缩写,字面意思是库存量单位, 简称SKU,定义为保存库存控制的最小可用单位,这是企业为了方便商品仓库管理而分配的商品编号,一种归类的方法.
详见: http://en.wikipedia.org/wiki/Stock_keeping_unit

更多
4 Responses Post a comment
  1. 荒野无灯

    @依云
    前面加了一个插件,对rss输出也生效了,导致feed停止输出了好些天,直到GR停止服务了,我试着用xianguo订阅,发现没更新。

  2. 依云

    好厉害呢~
    InoReader 一下子就显示了三篇新文章,是怎么回事呢?我看 GR 关闭前也没有你这里的文章呢。

Leave a Reply

Note: You may use basic HTML in your comments. Your email address will not be published.

Subscribe to this comment feed via RSS