记录一次Win7蓝屏分析与解决——Windows表示这锅我不背

fanruinet

记录一次Win7蓝屏分析与解决——Windows表示这锅我不背

这是2017年的事了，最近清理硬盘时发现了当时的dmp文件，于是又想起了这次debug的经历。

现象：同事抱怨装有Win7的笔记本总是无缘无故蓝屏，经常是在写文档的过程中蓝屏，没有任何征兆，多的时候每天会出现四五次，已经影响工作了。这种没有征兆的蓝屏本来就是最难处理的一类问题，我本来打算建议同事重装系统，但盯着蓝屏的底部提示memory dump已生成的提示信息，心想不如死马当活马医，搞不定再重装也不迟。于是拿到了附件中的两个文件，其中的dmp文件是mini kernel dump，xml文件是同时生成的系统信息。

在我自己的电脑上用WinDbg通过File菜单->Open Crush Dump打开112217-12495-01.dmp文件，经过几十秒加载符号文件之后，提示如下：

Loading Dump File [E:\Crashes\WinCrash\112217-12495-01.dmp]

Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*

Executable search path is:

Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x86 compatible

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 7601.23915.x86fre.win7sp1_ldr.170913-0600

Machine Name:

Kernel base = 0x8443b000 PsLoadedModuleList = 0x84587e30

Debug session time: Wed Nov 22 15:13:27.330 2017 (UTC + 8:00)

System Uptime: 0 days 6:41:15.205

Loading Kernel Symbols

.

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.

Run !sym noisy before .reload to track down problems loading symbols.

..............................................................

................................................................

..................................

Loading User Symbols

Loading unloaded module list

........

For analysis of this file, run !analyze -v

分析dump所用的命令在最后一行已经提示了，运行!analyze -v：

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0203030d, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 952831eb, address which referenced memory

Debugging Details:
------------------

Unable to load image \SystemRoot\system32\DRIVERS\athr.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for athr.sys

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.Sec
    Value: 1

    Key  : Analysis.DebugAnalysisProvider.CPP
    Value: Create: 8007007e on FR

    Key  : Analysis.DebugData
    Value: CreateObject

    Key  : Analysis.DebugModel
    Value: CreateObject

    Key  : Analysis.Elapsed.Sec
    Value: 36

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 92

    Key  : Analysis.System
    Value: CreateObject


BUGCHECK_CODE:  d1

BUGCHECK_P1: 203030d

BUGCHECK_P2: 2

BUGCHECK_P3: 0

BUGCHECK_P4: ffffffff952831eb

READ_ADDRESS: 84567c50: Unable to get Flags value from nt!KdVersionBlock
84567c50: Unable to get Flags value from nt!KdVersionBlock
84567c50: Unable to get Flags value from nt!KdVersionBlock
Unable to get MmSystemRangeStart
GetUlongPtrFromAddress: unable to read from 845a8208
GetUlongPtrFromAddress: unable to read from 845a86ec
Unable to get NonPagedPoolStart
Unable to get PagedPoolStart
0203030d

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

TRAP_FRAME:  c3aec258 -- (.trap 0xffffffffc3aec258)
ErrCode = 00000000
eax=02030301 ebx=c3aec374 ecx=94e6d802 edx=00000000 esi=87d7ade0 edi=844077a0
eip=952831eb esp=c3aec2cc ebp=c3aec320 iopl=0         nv up ei pl zr na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246
tdx!TdxCallConnectionHandler+0x131:
952831eb 8b700c          mov     esi,dword ptr [eax+0Ch] ds:0023:0203030d=????????
Resetting default scope

STACK_TEXT:  
c3aec258 952831eb badb0d00 00000000 00000000 nt!KiTrap0E+0x1b3
c3aec320 95284839 87d7ade0 c3aec374 00000000 tdx!TdxCallConnectionHandler+0x131
c3aec358 8dcacfe6 87d38528 c3aec302 8b9a6158 tdx!TdxEventInspectTransportAddress+0xff
c3aec3c8 8dc45a43 8b9a6158 872da6b8 87e84928 tcpip!TcpInspectConnectionOnListener+0xe7
c3aec418 8dc7bc51 87e84928 8b9a6158 c3aec490 tcpip!TcpListenerReceive+0x393
c3aec484 8dc7c0ab 8797daf0 87e79000 00000000 tcpip!TcpMatchReceive+0x60f
c3aec4d4 8dc7c0ec 87e84928 87e79000 000066d0 tcpip!TcpPreValIDAtedReceive+0x293
c3aec4f0 8dc76392 87e84928 87e79000 c3aec52c tcpip!TcpReceive+0x2d
c3aec500 8dc7e655 c3aec514 c000023e 00000000 tcpip!TcpNlClientReceiveDatagrams+0x12
c3aec52c 8dc7df97 8dcfa0b0 c3aec580 c000023e tcpip!IppDeliverListToProtocol+0x49
c3aec54c 8dc7c359 8dcf9ec0 00000006 c3aec580 tcpip!IppProcessDeliverList+0x2a
c3aec5a4 8dc7de40 8dcf9ec0 00000006 00000000 tcpip!IppReceiveHeaderBatch+0x1fb
c3aec638 8dc8c533 884db008 00000000 00000001 tcpip!IpFlcReceivePackets+0xbe5
c3aec6b8 8dc86a70 8a60d4b8 877aa3b8 00000000 tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x74e
c3aec6ec 844c4c7d 877aa3b8 ee316b32 87e42420 tcpip!FlReceiveNetBufferListChainCalloutRoutine+0x11e
c3aec754 8dc86bde 8dc86952 c3aec77c 00000000 nt!KeExpandKernelStackAndCalloutEx+0x132
c3aec790 8da6f18d 8a60d402 877aa300 00000000 tcpip!FlReceiveNetBufferListChain+0x7c
c3aec7c8 8da5d5be 86ee1aa8 877aa3b8 00000000 ndis!ndisMIndicateNetBufferListsToOpen+0x188
c3aec7f0 8da5d4b2 00000000 877aa3b8 8a604878 ndis!ndisIndicateSortedNetBufferLists+0x4a
c3aec96c 8da08c2d 8831d0e0 00000000 00000000 ndis!ndisMDispatchReceiveNetBufferLists+0x129
c3aec988 8da398fc 8831d0e0 877aa3b8 00000000 ndis!ndisMTopReceiveNetBufferLists+0x2d
c3aec9a4 8da39896 8a623748 877aa3b8 00000000 ndis!ndisFilterIndicateReceiveNetBufferLists+0x46
c3aec9c0 9c9618bd 8a623748 877aa3b8 00000000 ndis!NdisFIndicateReceiveNetBufferLists+0x2f
c3aec9e8 9c9656a9 8a623748 8962ba10 8962b9c0 nwifi!Dot11IndicateRecvPackets+0x51
c3aeca08 8da398fc 8a624488 877aa3b8 00000000 nwifi!Pt6Receive+0x1d5
c3aeca24 8da39896 895f1008 88554018 00000000 ndis!ndisFilterIndicateReceiveNetBufferLists+0x46
c3aeca40 95359c85 895f1008 88554018 00000000 ndis!NdisFIndicateReceiveNetBufferLists+0x2f
c3aeca6c 8da5d553 8962b014 88554018 00000000 vwififlt!FilterReceiveNetBufferLists+0xcf
c3aeca94 8da08c88 8831d0e0 88554018 00000000 ndis!ndisMIndicateReceiveNetBufferListsInternal+0x62
c3aecabc 9624aa9f 8831d0e0 88554018 00000000 ndis!NdisMIndicateReceiveNetBufferLists+0x52
WARNING: Stack unwind information not available. Following frames may be wrong.
c3aecb00 96249df8 891e6020 00000001 00000000 athr+0x29a9f
c3aecb1c 963708f7 891e6020 c3aecb50 9637e5fb athr+0x28df8
c3aecb28 9637e5fb 891f4020 00010001 8952d468 athr+0x14f8f7
c3aecb50 9625ec5d 891f4020 c3aecb6c 96222a81 athr+0x15d5fb
c3aecb5c 96222a81 86edb020 891e6020 c3aecbac athr+0x3dc5d
c3aecb6c 8da5d892 891e6020 00000002 00000000 athr+0x1a81
c3aecbac 8da3f56a 8952d93c 0052d468 00000002 ndis!ndisMiniportDpc+0xda
c3aecc0c 8da0e8e0 8952dd3c 00000000 873218e8 ndis!ndisQueuedMiniportDpcWorkItem+0xd0
c3aecc50 8464863d 00000000 ee3160f6 00000000 ndis!ndisReceiveWorkerThread+0x161
c3aecc90 844ecab9 8da0e77f 00000000 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19


SYMBOL_NAME:  tdx!TdxCallConnectionHandler+131

MODULE_NAME: tdx

IMAGE_NAME:  tdx.sys

IMAGE_VERSION:  6.1.7601.23880

STACK_COMMAND:  .thread ; .cxr ; kb

FAILURE_BUCKET_ID:  0xD1_tdx!TdxCallConnectionHandler+131

OS_VERSION:  7.1.7601.23915

BUILDLAB_STR:  win7sp1_ldr

OSPLATFORM_TYPE:  x86

OSNAME:  Windows 7

FAILURE_ID_HASH:  {4e9fda1e-b72d-cf5b-289f-336fcec76ff2}

Followup:     MachineOwner
---------

根据这段分析报告中给出的猜测：
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
很可能是某个驱动程序使用了错误的指针。那么我要找出具体是哪一个驱动程序的锅。继续往下看：
Unable to load image \SystemRoot\system32\DRIVERS\athr.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for athr.sys
这一句提示无法加载athr.sys，为什么只有这一个文件提示出错呢？我猜这个文件应该来自第三方，不属于Windows。在下面的“STACK_TEXT”中也可以看到，栈中确实有athr，这几行只显示内存地址，而其他的call frame都是来自ndis、nt、tcpip这些系统组件，跟我的猜测是一致的。追查一下athr.sys这个文件，在WER-43227-0.sysdata.xml中直接搜athr.sys：
<DESCRIPTION>Qualcomm Atheros AR938x Wireless Network Adapter</DESCRIPTION>
<HARDWAREID>PCI\VEN_168C&amp;DEV_0030&amp;SUBSYS_3112168C&amp;REV_01</HARDWAREID>
<SERVICE>athr</SERVICE>
<DRIVER>athr.sys</DRIVER>
根据DESCRIPTION，它是高通无线网卡的驱动。虽然根据以上信息还不能确定一定是它的锅，但至少可以尝试一下最新的版本。按型号在官网上一查，果然已经有了更新版本的驱动。在同事的电脑上安装最新版本之后，蓝屏再也没有出现过。

这次分析与解决蓝屏的过程其实非常简单，我从中学到了下面几点：
1. 并不是所有的蓝屏都是Windows的锅，第三方软件嫌疑也很大；
2. 蓝屏看似可怕，但如果尝试去分析一下，会发现至少有一些蓝屏并不难解决；
3. 如果没有找到原因，仍然用笔记本自带的bug驱动，即使重装系统也未必解决问题。
CrashDump_20171122.zip (38.35 KB, 下载次数: 90)

2021-8-10 03:57 上传

点击文件名下载附件
Crash Memory Dump

fanruinet

I籽丶轩 发表于 2021-8-11 09:27
分析思路不错，我都不知道还有个xml文件，一般都是找到信息点然后上网查一下是什么东西，再找解决方案

那个xml文件名是WER开头的，说明是Windows Error Reporting生成的。如果加入了“Windows体验改进计划”，那么WER会把dmp和xml上传到微软的服务器，微软会有人对故障原因进行分析。如果确实是windows的问题，微软肯定会修复的。如果是驱动的问题，那么微软也能够根据驱动签名联系到生产厂家进行修复。
windows的bug或驱动bug通常不会只有一个人遇到，微软很可能已经修复了。这个帖子里遇到的问题很可能就属于这种情况。

叫我Wait啦

思路学习了~

Mainos

前排学习

火车不出轨

666厉害  

swjia

关键是重装系统后，可能这个网卡驱动是最新版本的，问题也解决了。所以蓝屏还是装系统快一些。

ddwwtom

学习了，谢谢楼主

newman3301

较少使用调试软件，受教了。谢谢。

bjxiaoyao

内容精彩，感谢分享。

Tamluo

我倒是不敢随便更新驱动，win10，很容易当机

nekotann

感谢分享