引用注明>> 【作者:张佩】【原文:www.YiiYee.cn/blog】
这篇文件是对上一篇《奇妙的系统性能问题》的补充。我在经历那次性能陡降问题困扰的过程中,还碰到了一次BSOD。当蓝屏发生的时候,我甚至是兴奋的。因为在此之前,我一直都认为问题是系统或软件模块导致的。而蓝屏正好是分析的切入点。所以当分析了这个dump后,我立刻扭转了方向,判断认为:确实是磁盘坏了。
这个结论是正确的,但却不完备的。因为最后的结果是磁盘并没有坏,而是受到了外部环境的干扰。
这个dump文件弥足珍贵,因为正常情况下,这种伤硬盘的实验我们是不会主动去做的。所以这个dump文件完全得于碰巧,在此进行分析。
1: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* KERNEL_DATA_INPAGE_ERROR (7a) The requested page of kernel data could not be read in. Typically caused by a bad block in the paging file or disk controller error. Also see KERNEL_STACK_INPAGE_ERROR. If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185, it means the disk subsystem has experienced a failure. If the error status is 0xC000009A, then it means the request failed because a filesystem failed to make forward progress. Arguments: Arg1: ffffc00006694e90, lock type that was held (value 1,2,3, or PTE address) Arg2: ffffffffc0000185, error status (normally i/o status code) Arg3: 0000000042bde860, current process (virtual address for lock type 3, or PTE) Arg4: fffff960002fdcc0, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address) Debugging Details: ------------------ ERROR_CODE: (NTSTATUS) 0xc0000185 - The I/O device reported an I/O error. DISK_HARDWARE_ERROR: There was error with disk hardware BUGCHECK_STR: 0x7a_c0000185 DEFAULT_BUCKET_ID: CODE_CORRUPTION PROCESS_NAME: explorer.exe CURRENT_IRQL: 0
根据Windbg的Help文档,bug check的4个参数分析如下:
Parameter |
Description |
1 | The address of the page table entry (PTE) |
2 | The error status (usually an I/O status code) |
3 | The PTE contents |
4 | The faulting address |
Arg1: ffffc00006694e90, PTE地址
Arg2: ffffffffc0000185, 错误码
Arg3: 0000000042bde860, PTE,即参数1所在地址的值
Arg4: fffff960002fdcc0, 需要被page in但发生错误的地址
下面是一些详细信息:
1: kd> dd ffffc00006694e90 L1 ffffc000`06694e90 42bde860 1: kd> !error 0xc0000185 Error code: (NTSTATUS) 0xc0000185 (3221225861) - The I/O device reported an I/O error.
当前的调用栈如下:
1: kd> kn # Child-SP RetAddr Call Site 00 ffffd000`26675b78 fffff802`bf64d0ea nt!DbgBreakPointWithStatus 01 ffffd000`26675b80 fffff802`bf64c9fb nt!KiBugCheckDebugBreak+0x12 02 ffffd000`26675be0 fffff802`bf5c4da4 nt!KeBugCheck2+0x8ab 03 ffffd000`266762f0 fffff802`bf5ed973 nt!KeBugCheckEx+0x104 04 ffffd000`26676330 fffff802`bf4da190 nt!MiWaitForInPageComplete+0x11065f 05 ffffd000`26676420 fffff802`bf4b318f nt!MiIssueHardFault+0x184 06 ffffd000`266764e0 fffff802`bf5cef2f nt!MmAccessFault+0x3cf 07 ffffd000`26676620 fffff960`002fdcc0 nt!KiPageFault+0x12f 08 ffffd000`266767b8 fffff960`00199320 win32k!CleanupShadow 09 ffffd000`266767c0 fffff960`001833db win32k!xxxFreeWindow+0x9ec 0a ffffd000`26676850 fffff960`0019ab61 win32k!xxxDestroyWindow+0x30f 0b ffffd000`26676910 fffff960`00174968 win32k!xxxRemoveShadow+0x7d 0c ffffd000`26676940 fffff960`00174b90 win32k!xxxSendChangedMsgs+0x230 0d ffffd000`266769c0 fffff960`001611ac win32k!xxxEndDeferWindowPosEx+0x204 0e ffffd000`26676a80 fffff960`0014c675 win32k!xxxSetWindowPosAndBand+0xc0 0f ffffd000`26676b10 fffff960`0014c26a win32k!xxxSetWindowPos+0x29 10 ffffd000`26676b60 fffff960`0014b86f win32k!xxxShowWindow+0x1a6 11 ffffd000`26676bf0 fffff802`bf5d04b3 win32k!NtUserShowWindow+0xab 12 ffffd000`26676c40 00007ffa`2e44119a nt!KiSystemServiceCopyEnd+0x13 13 00000000`0335f448 00007ffa`2a4554cc USER32!ZwUserShowWindow+0xa 14 00000000`0335f450 00000000`01139c00 Comctl32!InitCommonControls+0x18cc 15 00000000`0335f458 00000000`0001009a 0x1139c00 16 00000000`0335f460 00000000`00000001 0x1009a 17 00000000`0335f468 00000000`00000001 0x1 18 00000000`0335f470 00000000`00000001 0x1 19 00000000`0335f478 00007ffa`2a48252f 0x1 1a 00000000`0335f480 00000000`000100be Comctl32!CCEnableScrollBar+0x4f83 1b 00000000`0335f488 00000000`0001009a 0x100be 1c 00000000`0335f490 00000000`fffffdf6 0x1009a 1d 00000000`0335f498 000024ed`e852e2d2 0xfffffdf6 1e 00000000`0335f4a0 00000000`00000006 0x000024ed`e852e2d2 1f 00000000`0335f4a8 00007ffa`2a4824e1 0x6 20 00000000`0335f4b0 00000000`00000000 Comctl32!CCEnableScrollBar+0x4f35
这个调用栈可以被简单地分成三个部分:
Frame 0-7:这是处理页错误的部分,处理过程中发生了硬件错误(Hardware Fault),最后调用KeBugCheckEx产生蓝屏。
Frame 8-12:这是在内核的Win32k模块中进行绘图操作的部分。
Frame 13-20:这是Explorer进程的用户模块部分。
重要的是第一和第二部分。为什么会从Win32k执行,转入页错误处理呢?如果没有页错误处理,蓝屏是不会立刻发生的。看一下第二部分最上面那个函数的地址:
1: kd> x win32k!CleanupShadow fffff960`002fdcc0 win32k!CleanupShadow (void)
这个值正是bug check的第三个参数。这样问题就清晰了起来了:函数win32k!CleanupShadow所在的代码页已经被换出到页文件中,当调用到它的时候,系统必须把它所在的页文件换入系统内存中;在做换入操作的时候,可能是长时间震动而导致了物理磁片损坏,磁盘驱动无法从磁盘中读取相关页的内容,导致了蓝屏。
从系统的角度来讲,它可以认为Win32k的镜像文件已经被破损了。这时候如果检查一下win32k模块的镜像文件完整性,错误就多得吓人了。
1: kd> !chkimg win32k -d fffff960001906ff-fffff9600019070e 16 bytes - win32k!W32pServiceTable+fff [ ff a0 83 40 00 60 f9 ff:02 86 4f 75 01 40 fa 95 ] fffff96000190710-fffff9600019071a 11 bytes - win32k!W32pServiceTable+1010 (+0x11) [ a0 83 40 00 60 f9 ff ff:00 b5 0f 02 00 47 62 00 ] fffff9600019071c-fffff9600019072a 15 bytes - win32k!W32pServiceTable+101c (+0x0c) [ 60 f9 ff ff a0 83 40 00:00 43 27 01 c0 dd 0f 02 ] fffff9600019072c-fffff96000190736 11 bytes - win32k!W32pServiceTable+102c (+0x10) [ 60 f9 ff ff a0 83 40 00:00 a2 0e 01 00 c5 75 01 ] fffff96000190738-fffff9600019073a 3 bytes - win32k!W32pServiceTable+1038 (+0x0c) [ a0 83 40:00 00 00 ] // …省略 4756 errors : !win32k (fffff960001906ff-fffff960002fdfff)
这表明磁盘的质量很重要,要是在使用过程中磁盘出了问题,如果运气不差的话,发生在普通文件区域,最多是文件破损导致无法读写;但如果碰巧是页文件所在磁盘区出了问题,那么系统会很快死翘翘的。
5,917 total views, 3 views today
你好,我剛買了 CY001 V2.0 UBS 開發版,非常有用,並錄制了個 “WDK 驅動開發入門 – 小白視頻教學” 視頻上中下。由於使用了 CY001,所以,現特意知會。
http://23.244.68.57/wdk-%E9%A9%85%E5%8B%95%E9%96%8B%E7%99%BC%E5%85%A5%E9%96%80-%E5%B0%8F%E7%99%BD%E8%A6%96%E9%A0%BB%E6%95%99%E5%AD%B8-%E4%B8%8A/
視頻地址:
http://www.dailymotion.com/video/x1o08dt_wdk-%E9%A9%85%E5%8B%95%E9%96%8B%E7%99%BC%E5%85%A5%E9%96%80-%E5%B0%8F%E7%99%BD%E8%A6%96%E9%A0%BB%E6%95%99%E5%AD%B8-%E4%B8%8A_tech
http://www.dailymotion.com/video/x1o090l_wdk-%E9%A9%85%E5%8B%95%E9%96%8B%E7%99%BC%E5%85%A5%E9%96%80-%E5%B0%8F%E7%99%BD%E8%A6%96%E9%A0%BB%E6%95%99%E5%AD%B8-%E4%B8%AD_tech
http://www.dailymotion.com/video/x1o08mv_wdk-%E9%A9%85%E5%8B%95%E9%96%8B%E7%99%BC%E5%85%A5%E9%96%80-%E5%B0%8F%E7%99%BD%E8%A6%96%E9%A0%BB%E6%95%99%E5%AD%B8-%E4%B8%8B_tech
Great and thanks kazuya!.
您好,
上面您說到:
函數win32k!CleanupShadow所在的代碼頁已經被換出到頁文件中.
請問是怎麼看出來的? 是因為預期為0000000042bde860, 但實際上卻是fffff960`002fdcc0, 兩者不同所得的結論嗎?
謝謝.
可以从call stack的后续函数看出。win32k!CleanupShadow偏移为0,说明没有执行哪怕一条此函数的指令。然后是页错误处理。由此可推理而出。