Re: 诊断方法-已签名的win7 release版文件系统驱动在客户现场概率性蓝屏问题

Windows内核调试

诊断方法-已签名的win7 release版文件系统驱动在客户现场概率性蓝屏问题

gfang 2012-09-03, 14:37 下午
各位老师好：

我想请教的是：有哪些更好的方法可以用来诊断这个问题。

如标题里叙述的，我现在有一个windows 7平台上的release版文件系统驱动在现场概率性蓝屏(可能跟现场环境有关)，因为是签过名的releae驱动，好不容易拿回来的dump跟源代码对不上，不容易定位导致蓝屏的原因，而现场的特殊性又使得无论是请现场人员帮助做一些诊断测试还是亲自到现场去做调试都不太可能。

因此想请教，有哪些通用的方法用来诊断这一类问题(签名驱动dump跟源码匹配不上，长时间运行偶发蓝屏，远程诊断)？ 
谢谢


Re: 诊断方法-已签名的win7 release版文件系统驱动在客户现场概率性蓝屏问题

格蠹老雷 2012-09-03, 22:16 下午

深入分析dump :-)

能有dump文件就很好啊，这样的复杂问题能依赖符号定位到函数一级就足够了，源代码是在是无足轻重...

什么Stop Code？0A, 1E?

Re: 诊断方法-已签名的win7 release版文件系统驱动在客户现场概率性蓝屏问题

gfang 2012-09-04, 09:09 上午
多谢张老师

BugCheck 50, {ffffffff80000bdc, 0, fffff800041b30f3, 5}
PAGE_FAULT_IN_NONPAGED_AREA

就是说就算是签过名的Release版驱动，dump结合pdb仍能正确地指向函数级别 是吗

另外我需要在代码中做什么特别的动作(预诊断措施)来配合这种可能出现的情况吗

再次感谢

Re: 诊断方法-已签名的win7 release版文件系统驱动在客户现场概率性蓝屏问题

格蠹老雷 2012-09-04, 21:13 下午

位于 fffff800041b30f3的代码访问ffffffff80000bdc触发了缺页异常...

是的

Re: 诊断方法-已签名的win7 release版文件系统驱动在客户现场概率性蓝屏问题

gfang 2012-09-07, 19:22 下午
用一个更新了部分代码的checked版驱动发到现场，现在不蓝屏了，更新的代码可能修正了潜在的BUG,但是不能确定问题是否真正得到了解决(其他环境因素可可能发生了变化，所以没法进行单一变量的测试)

我使用了以下操作来分析dump
!sym noisy
.reload /i myfs.sys
!analyze -v

这时栈回溯信息里关联到源代码了，但是指向了明显不会执行到的地方，所以我怀疑匹配是错的
张老师说即使是签过名的release版驱动仍可以正确定位到函数级别 我对这块不太清楚，不知道要怎么弄，特来请教

谢谢

Re: 诊断方法-已签名的win7 release版文件系统驱动在客户现场概率性蓝屏问题

gfang 2012-09-07, 20:06 下午
3: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: ffffffff80000ad8, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffff800041a80f3, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000005, (reserved)

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

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
***                                                                   ***
***                                                                   ***
***    Your debugger is not using the correct symbols                 ***
***                                                                   ***
***    In order for this command to work properly, your symbol path   ***
***    must point to .pdb files that have full type information.      ***
***                                                                   ***
***    Certain .pdb files (such as the public OS symbols) do not      ***
***    contain the required information.  Contact the group that      ***
***    provided you with these symbols if you need this command to    ***
***    work.                                                          ***
***                                                                   ***
***    Type referenced: nt!_KPRCB                                     ***
***                                                                   ***
*************************************************************************
。
。
。

ADDITIONAL_DEBUG_TEXT:  
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: myfs

FAULTING_MODULE: fffff80004003000 nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4ffa5638

READ_ADDRESS:  ffffffff80000ad8 

FAULTING_IP: 
nt!ExFreePoolWithTag+43
fffff800`041a80f3 418b45f0        mov     eax,dword ptr [r13-10h]

MM_INTERNAL_CODE:  5

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x50

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff800040f2b91 to fffff80004074f00

STACK_TEXT:  
fffff880`05cd8f98 fffff800`040f2b91 : 00000000`00000050 ffffffff`80000ad8 00000000`00000000 fffff880`05cd9100 : nt!KeBugCheckEx
fffff880`05cd8fa0 fffff800`04072fee : 00000000`00000000 00000000`00000800 00000000`00000000 00000000`00000000 : nt!wcsncat_s+0x2d3a9
fffff880`05cd9100 fffff800`041a80f3 : 00000000`00000020 00000000`00000000 00000000`00000001 fffff880`05cd9300 : nt!KeSynchronizeExecution+0x28de
fffff880`05cd9290 fffff880`0513f4c0 : fffffa80`06fdecf0 00000000`00000080 fffffa80`474c444c 00000000`0000042f : nt!ExFreePoolWithTag+0x43
fffff880`05cd9340 fffff880`05171223 : fffff880`05194fa0 00000000`c0000011 00000000`00000000 00000000`00000000 : myfs+0xe4c0
fffff880`05cd94d0 fffff880`0518e859 : fffffa80`0717fa80 fffffa80`07426430 fffffa80`0717fa80 00000000`00000000 : myfs+0x40223
fffff880`05cd9500 fffff880`05179b60 : fffff8a0`035d6710 fffffa80`07426548 fffffa80`07426430 fffff880`00000000 : myfs+0x5d859
fffff880`05cd9560 fffff880`0517a919 : fffffa80`0717fa80 fffffa80`07426430 00000000`00000001 00000000`00000001 : myfs+0x48b60
fffff880`05cd95b0 fffff880`05144f87 : fffffa80`0717fa80 fffffa80`07426430 fffffa80`0940c900 00000000`00000000 : myfs+0x49919
fffff880`05cd96f0 fffff880`05178d54 : fffff880`05154130 00000000`00000800 fffffa80`07c9ed40 fffffa80`0940c920 : myfs+0x13f87
fffff880`05cd97f0 fffff880`05165b7a : fffffa80`0976c248 fffffa80`07c9d8b0 fffffa80`07519f80 fffffa80`07519e01 : myfs+0x47d54
fffff880`05cd9820 fffff880`015f5271 : fffffa80`074f6c70 fffffa80`07426430 fffffa80`07115c30 fffffa80`07c9dd00 : myfs+0x34b7a
fffff880`05cd9850 fffff880`015f3138 : fffff8a0`001db400 fffffa80`074f6c70 00000000`00000001 00000000`00000000 : mup!MupSurrogateGetUncProviderDeviceObject+0x1491
fffff880`05cd98c0 fffff880`015f3b0d : fffffa80`07426430 fffff880`015f1110 fffffa80`070d9ed0 00000000`00000000 : mup!MupSurrogatePurgeNegativeCacheEntry+0x33b0
fffff880`05cd9910 fffff880`010b723f : fffffa80`074265d8 fffffa80`074f6c70 fffff880`05cd99a0 fffffa80`07519e30 : mup!MupSurrogatePurgeNegativeCacheEntry+0x3d85
fffff880`05cd9960 fffff880`010b56df : fffffa80`07c9dd40 00000000`00000001 fffffa80`07c9dd00 fffffa80`07426430 : fltmgr!FltIsCallbackDataDirty+0xa2f
fffff880`05cd99f0 fffff800`04388929 : 00000000`00000000 fffffa80`070d9ed0 00000000`00000001 fffffa80`07426430 : fltmgr+0x16df
fffff880`05cd9a50 fffff800`04390143 : fffffa80`070d9ed0 fffffa80`070d9ed0 fffffa80`070d9ed0 fffff880`045d5180 : nt!IoRemoveShareAccess+0x169
fffff880`05cd9ac0 fffff800`04074153 : 00000000`00002b2c 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtReadFile+0x633
fffff880`05cd9bb0 00000000`7738ff1a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeSynchronizeExecution+0x3a43
00000000`4d15f838 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7738ff1a


STACK_COMMAND:  kb

FOLLOWUP_IP: 
myfs+e4c0
fffff880`0513f4c0 8bc7            mov     eax,edi

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  myfs+e4c0

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  myfs.sys

BUCKET_ID:  WRONG_SYMBOLS

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

Re: 诊断方法-已签名的win7 release版文件系统驱动在客户现场概率性蓝屏问题

格蠹老雷 2012-09-08, 18:49 下午
Verifier > 对myfs启用pool checking > 重启后重现问题

Re: 诊断方法-已签名的win7 release版文件系统驱动在客户现场概率性蓝屏问题

gfang 2012-09-08, 22:26 下午
之前试过verifier，设置后重启点用户名登陆，显示桌面前就会被verifier给直接bugcheck  不过verifier里除pool checking选项外还选了special pool和IRQL checking

Powered by Community Server Powered by CnForums.Net