Re: BugCheck 77, {0, 80545c3c, 0, f795ed24}，高手帮看下

WinDbg

BugCheck 77, {0, 80545c3c, 0, f795ed24}，高手帮看下

Jerry 2009-11-20, 11:07 上午

*** Fatal System Error: 0x00000077
(0x00000000,0x80545C3C,0x00000000,0xF795ED24)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

Connected to Windows XP 2600 x86 compatible target at (Thu Nov 19 17:39:23.219 2009

(GMT+8)), ptr64 FALSE
Loading Kernel Symbols
...............................................................
...
Loading User Symbols

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 77, {0, 80545c3c, 0, f795ed24}

Probably caused by : memory_corruption ( nt!MmInPageKernelStack+176 )

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

nt!RtlpBreakWithStatusInstruction:
8052b5dc cc              int     3
1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KERNEL_STACK_INPAGE_ERROR (77)
The requested page of kernel data could not be read in. Caused by
bad block in paging file or disk controller error.
In the case when the first arguments is 0 or 1, the stack signature
in the kernel stack was not found. Again, bad hardware.
An I/O status of c000009c (STATUS_DEVICE_DATA_ERROR) or
C000016AL (STATUS_DISK_OPERATION_FAILED) normally indicates
the data could not be read from the disk due to a bad
block. Upon reboot autocheck will run and attempt to map out the bad
sector. If the status is C0000185 (STATUS_IO_DEVICE_ERROR) and the paging
file is on a SCSI disk device, then the cabling and termination should be
checked. See the knowledge base article on SCSI termination.
Arguments:
Arg1: 00000000, (page was retrieved from page cache)
Arg2: 80545c3c, value found in stack where signature should be
Arg3: 00000000, 0
Arg4: f795ed24, address of signature on kernel stack

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

ERROR_CODE: (NTSTATUS) 0 - STATUS_WAIT_0

BUGCHECK_STR: 0x77_0

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from 804f8df9 to 8052b5dc

STACK_TEXT:
f797e90c 804f8df9 00000003 f797ec68 00000000 nt!RtlpBreakWithStatusInstruction
f797e958 804f99e4 00000003 85fc23c8 00000000 nt!KiBugCheckDebugBreak+0x19
f797ed38 804f9f33 00000077 00000000 80545c3c nt!KeBugCheck2+0x574
f797ed58 80512e18 00000077 00000000 80545c3c nt!KeBugCheckEx+0x1b
f797ed8c 8053fd76 00fc23c8 00000000 85fba8b8 nt!MmInPageKernelStack+0x176
f797eda4 80540246 85fc2428 805cff64 00000000 nt!KiInSwapKernelStacks+0x16
f797edac 805cff64 00000000 00000000 00000000 nt!KeSwapProcessOrStack+0x7c
f797eddc 805460de 805401ca 00000000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!MmInPageKernelStack+176
80512e18 8a550b mov dl,byte ptr [ebp+0Bh]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: nt!MmInPageKernelStack+176

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4802516a

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: 0x77_0_nt!MmInPageKernelStack+176

BUCKET_ID: 0x77_0_nt!MmInPageKernelStack+176

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

1: kd> lmvm nt
start end module name
804d7000 806e4000 nt (pdb symbols) d:\symbols\xpsp3

\ntkrpamp.pdb\7D6290E03E32455BB0E035E38816124F1\ntkrpamp.pdb
    Loaded symbol image file: ntkrpamp.exe
    Image path: ntkrpamp.exe
    Image name: ntkrpamp.exe
    Timestamp:        Mon Apr 14 02:31:06 2008 (4802516A)
    CheckSum:         001F442E
    ImageSize:        0020D000
    File version:     5.1.2600.5512
    Product version: 5.1.2600.5512
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft® Windows® Operating System
    InternalName:     ntkrpamp.exe
    OriginalFilename: ntkrpamp.exe
    ProductVersion:   5.1.2600.5512
    FileVersion:      5.1.2600.5512 (xpsp.080413-2111)
    FileDescription: NT Kernel & System
    LegalCopyright:   © Microsoft Corporation. All rights reserved.

小弟新学Windbg，这个问题高手帮忙看下可以吗，给指出一个方向也可以。谢谢了先

Re: BugCheck 77, {0, 80545c3c, 0, f795ed24}，高手帮看下

Jerry 2009-11-20, 16:20 下午
（1）我的理解是：调用nt!MmInPageKernelStack的时候出现了问题，然后调用了蓝屏相关的：
nt!KeBugCheckEx，nt!KeBugCheck2，nt!KiBugCheckDebugBreak，nt!RtlpBreakWithStatusInstruction函数。不知道我的理解是否正确，请高手解答下。
（2）nt!MmInPageKernelStack是干什么用的，是指把kernel stack 的paging file读到memory吗？
（3）nt!MmInPageKernelStack有相关的资料可以查询吗，WDK?WDDK?或者其他？

Re: BugCheck 77, {0, 80545c3c, 0, f795ed24}，高手帮看下

Jerry 2009-11-20, 16:51 下午
怎么没人回我？是问题太简单了吗？
进来看的多少给点提示啊，在此谢谢了先。

Re: BugCheck 77, {0, 80545c3c, 0, f795ed24}，高手帮看下

nightxie 2009-11-20, 16:53 下午

看下面这段。。。

ntkrnlpa!MmInPageKernelStack+0x158:
00438ec8 8b4328          mov     eax,dword ptr [ebx+28h]
00438ecb 8b48fc          mov     ecx,dword ptr [eax-4]
00438ece 5f              pop     edi
00438ecf 5e              pop     esi
00438ed0 3bcb            cmp     ecx,ebx
00438ed2 5b              pop     ebx
00438ed3 740e            je      ntkrnlpa!MmInPageKernelStack+0x173 (00438ee3)

ntkrnlpa!MmInPageKernelStack+0x165:
00438ed5 50              push    eax
00438ed6 6a00            push    0
00438ed8 51              push    ecx
00438ed9 ff75f8          push    dword ptr [ebp-8]
00438edc 6a77            push    77h

ntkrnlpa!MmInPageKernelStack+0x16e:
00438ede e8c78dfeff call ntkrnlpa!KeBugCheckEx (00421caa)

ebx+28h是_ETHREAD->Tcb->KernelStack,
判断*((PULONG_PTR)StackInfo->KernelStack - 1)和函数的第一个参数EThread是否相等，如果不相等就给你一个BugCheck。。。

关于这个函数的说明是：
This routine makes the specified kernel stack resident

Re: BugCheck 77, {0, 80545c3c, 0, f795ed24}，高手帮看下

Jerry 2009-11-20, 17:07 下午
感谢楼上的回复，
ebx+28h是_ETHREAD->Tcb->KernelStack，我不太明白
*((PULONG_PTR)StackInfo->KernelStack - 1)和函数的第一个参数EThread是指【eax-4】和【ebx+28h】吗？
能具体讲下这两个东西吗？
再次感谢。

Re: BugCheck 77, {0, 80545c3c, 0, f795ed24}，高手帮看下

Jerry 2009-11-20, 17:45 下午
我是连着调试器后出现的蓝屏，那么
nt!KeBugCheckEx->nt!KeBugCheck2->nt!KiBugCheckDebugBreak->nt!RtlpBreakWithStatusInstruction

是用来中断到调试器的吗？
0: kd> uf nt!KiBugCheckDebugBreak
nt!KiBugCheckDebugBreak:
804f8de0 6a24 push 24h
804f8de2 6858974d80 push offset nt!RamdiskBootDiskGuid+0xcc (804d9758)
804f8de7 e8942d0400 call nt!_SEH_prolog (8053bb80)
804f8dec 33db xor ebx,ebx

nt!KiBugCheckDebugBreak+0xe:
804f8dee 895dfc mov dword ptr [ebp-4],ebx
804f8df1 ff7508 push dword ptr [ebp+8]
804f8df4 e8df270300 call nt!DbgBreakPointWithStatus (8052b5d8)
804f8df9 eb59 jmp nt!KiBugCheckDebugBreak+0x74 (804f8e54)

nt!KiBugCheckDebugBreak+0x74:
804f8e54 834dfcff or dword ptr [ebp-4],0FFFFFFFFh
804f8e58 837d0803 cmp dword ptr [ebp+8],3
804f8e5c 7590 jne nt!KiBugCheckDebugBreak+0xe (804f8dee)

nt!KiBugCheckDebugBreak+0x7e:
804f8e5e e8582d0400 call nt!_SEH_epilog (8053bbbb)
804f8e63 c20400 ret 4
0: kd> uf nt!DbgBreakPointWithStatus
nt!DbgBreakPointWithStatus:
8052b5d8 8b442404 mov eax,dword ptr [esp+4]
8052b5dc cc int 3
8052b5dd c20400 ret 4
这个int 3就是断到调试器了吧，如果我T下去是不是就可以绘制蓝屏，调用IoWriteCrashDump了？
那我可不可以理解：如果没接调试器，是不是这个nt!DbgBreakPointWithStatus不会执行？

Re: BugCheck 77, {0, 80545c3c, 0, f795ed24}，高手帮看下

nightxie 2009-11-20, 18:10 下午
对，如果没有被调试，就不会有KiBugCheckDebugBreak

Re: BugCheck 77, {0, 80545c3c, 0, f795ed24}，高手帮看下

Jerry 2009-11-20, 19:07 下午
nt!KeBugCheck2+0x4d6:
804f9946 817d08e2000000 cmp dword ptr [ebp+8],0E2h
804f994d 0f8491000000 je nt!KeBugCheck2+0x574 (804f99e4)

nt!KeBugCheck2+0x4e3:
804f9953 803d415a558000 cmp byte ptr [nt!KdDebuggerEnabled (80555a41)],0
804f995a 0f8484000000 je nt!KeBugCheck2+0x574 (804f99e4)

nt!KeBugCheck2+0x4f0:
804f9960 ff35b0d05580 push dword ptr [nt!KiBugCheckData+0x10 (8055d0b0)]
804f9966 ff35acd05580 push dword ptr [nt!KiBugCheckData+0xc (8055d0ac)]
804f996c ff35a8d05580 push dword ptr [nt!KiBugCheckData+0x8 (8055d0a8)]
804f9972 ff35a4d05580 push dword ptr [nt!KiBugCheckData+0x4 (8055d0a4)]
804f9978 ff35a0d05580 push dword ptr [nt!KiBugCheckData (8055d0a0)]
804f997e 68b8934f80 push offset nt!KiInvokeBugCheckEntryCallbacks+0xd2 (804f93b8)
804f9983 e8da1e0300 call nt!DbgPrint (8052b862)
804f9988 83c418 add esp,18h
804f998b 803d405a558000 cmp byte ptr [nt!KdDebuggerNotPresent (80555a40)],0
804f9992 7550 jne nt!KeBugCheck2+0x574 (804f99e4)
。。。。。。。
。。。。。。
nt!KeBugCheck2+0x56d:
804f99dd 6a03 push 3
804f99df e8fcf3ffff call nt!KiBugCheckDebugBreak (804f8de0)

nt!KeBugCheck2+0x574:
804f99e4 e85f830000 call nt!KeDisableInterrupts (80501d48)
。。。。。。
。。。。。。
nt!KeBugCheck2+0xa6e:
804f9ede 6a04 push 4
804f9ee0 e8fbeeffff call nt!KiBugCheckDebugBreak (804f8de0)
804f9ee5 8b4dfc mov ecx,dword ptr [ebp-4]
804f9ee8 5f pop edi
804f9ee9 5e pop esi
804f9eea 5b pop ebx
804f9eeb e8c842ffff call nt!KePrepareToLoseProcessorSpecificState (804ee1b8)
804f9ef0 c9 leave
804f9ef1 c21800 ret 18h

0: kd> d 80555a40
80555a40 00 01 00 00 01 00 00 00-00 00 00 00 00 00 00 00 ................

楼上所说的好像不太对，如果没有连接debugger，直接跳到574去执行nt!KeDisableInterrupts 关中断，确实不会执行KiBugCheckDebugBreak，但后面的a6e+2的地方还有一个KiBugCheckDebugBreak。我查了前面的跳转地址，最多跳到a6e，也就是说这个KiBugCheckDebugBreak一定会被执行。

Re: BugCheck 77, {0, 80545c3c, 0, f795ed24}，高手帮看下

格蠹老雷 2009-11-20, 21:26 下午
看起来这不是第一现场，感觉数据结构在此之前已经被破坏了，到这里才发作......
可以重现么？如何重现？蓝屏前做过什么（安装驱动，操作软硬件......）？
望闻问切，光切也不行:-)

Re: BugCheck 77, {0, 80545c3c, 0, f795ed24}，高手帮看下

Jerry 2009-11-21, 19:41 下午
<BLOCKQUOTE><table width="85%"><tr><td class="txt4"><img src="/Themes/default/images/icon-quote.gif"> <strong>Raymond wrote:</strong></td></tr><tr><td class="quoteTable"><table width="100%"><tr><td width="100%" valign="top" class="txt4">看起来这不是第一现场，感觉数据结构在此之前已经被破坏了，到这里才发作......
可以重现么？如何重现？蓝屏前做过什么（安装驱动，操作软硬件......）？
望闻问切，光切也不行:-)</td></tr></table></td></tr></table></BLOCKQUOTE>
感谢张老师的回复。
（1）您说的第一现场指的是？
我是用MS的Bootvis连着调试器跑reboot aging时出现的问题。第一次自动中断到调试器在第843次的，用命令生成dmp文件后继续跑；跑到941次的时候又自动中断到调试器，然后我将host端的信息复制过来发帖提问了。不知道这算不算第一现场？
（2）您说的切是指？

Re: BugCheck 77, {0, 80545c3c, 0, f795ed24}，高手帮看下

格蠹老雷 2009-11-23, 12:54 下午
Jerrt，上面的栈回溯让我们知道有个数据结构被破坏了，如何被破坏的无从知道；而这个数据破坏才是问题的关键，也就是我所说的“第一现场”。这是借用了刑侦领域的说法。
“切”指切脉，在这里比喻根据dump数据做技术分析。我的意思是“问”也很重要；了解背景信息，然后有所针对...
你说的用bootvis来做反复重启，这让我们知道这是个偶尔出现的问题，还有其他背景么，比如这是不是个处于开发中的平台，可能硬件还不稳定？...

Re: BugCheck 77, {0, 80545c3c, 0, f795ed24}，高手帮看下

Jerry 2009-11-23, 13:34 下午
明白了，感谢张老师的耐心解释。
这个平台是已经开发过的平台，量产了好几个月了，硬件应该很稳定了。
我用driver cd装了所有的driver和AP跑的reboot aging。