Re: [求助]文件系统BSOD原因分析
Windows内核调试
[求助]文件系统BSOD原因分析
gfang
2014-01-06, 11:50 上午
我们有一个文件系统驱动myfs.sys(类似FASTFAT)，现在测试发现在我们文件系统的两个卷间(比如S:盘，T:盘)间来回拷贝约包含100GB视频的文件时，有一定概率发生蓝屏。但是DUMP信息里没找到跟我们驱动相关的信息。求指点，非常感谢。
1: 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: fffff88004bbe0b8, memory referenced.
Arg2: 0000000000000001, value 0 = read operation, 1 = write operation.
Arg3: fffff80005c78a64, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000000, (reserved)
Debugging Details:
------------------
WRITE_ADDRESS: fffff88004bbe0b8
FAULTING_IP:
nt!ExAcquireResourceExclusiveLite+54
fffff800`05c78a64 f0480fba696000 lock bts qword ptr [rcx+60h],0
MM_INTERNAL_CODE: 0
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: System
CURRENT_IRQL: 0
TRAP_FRAME: fffff88004b9a6e0 -- (.trap 0xfffff88004b9a6e0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa800402e1a0 rbx=0000000000000000 rcx=fffff88004bbe058
rdx=fffff880009e6101 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80005c78a64 rsp=fffff88004b9a870 rbp=0000000000000001
r8=0000000000000001 r9=0000000000000090 r10=fffff80005c01000
r11=fffff8a001bba140 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up di pl zr na po nc
nt!ExAcquireResourceExclusiveLite+0x54:
fffff800`05c78a64 f0480fba696000 lock bts qword ptr [rcx+60h],0 ds:fffff880`04bbe0b8=????????????????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80005cf0694 to fffff80005c70880
STACK_TEXT:
fffff880`04b9a578 fffff800`05cf0694 : 00000000`00000050 fffff880`04bbe0b8 00000000`00000001 fffff880`04b9a6e0 :
nt!KeBugCheckEx
fffff880`04b9a580 fffff800`05c6e96e : 00000000`00000001 fffff880`04bbe058 00000000`00000100 fffff880`04b9a6d0 :
nt! ?? ::FNODOBFM::`string'+0x41db7
fffff880`04b9a6e0 fffff800`05c78a64 : fffffa80`076c5240 fffffa80`05a44800 00000000`000007ff 00000000`00000000 :
nt!KiPageFault+0x16e
fffff880`04b9a870 fffff880`01528b37 : 00000000`00000000 fffff880`04bbdb50 00000000`00000130 fffff800`05c46dd9 :
nt!ExAcquireResourceExclusiveLite+0x54
fffff880`04b9a8e0 fffff800`05f5a176 : 00000000`00000001 fffff880`016c12f7 fffff8a0`01bba270 fffff880`01639d31 :
fltmgr!DeleteStreamListCtrlCallback+0x27
fffff880`04b9a910 fffff880`016c0d20 : fffff8a0`01bba140 fffffa80`0402e1a0 fffff880`04b9a9e8 00000000`00000706 :
nt!FsRtlTeardownPerStreamContexts+0xe2
fffff880`04b9a960 fffff880`016c0a29 : 00000000`01010000 00000000`00000000 fffff800`05e15500 00000000`00000001 :
Ntfs!NtfsDeleteScb+0x108
fffff880`04b9a9a0 fffff880`0163930c : fffff8a0`01bba040 fffff8a0`01bba140 fffff800`05e15500 fffff880`04b9ab12 :
Ntfs!NtfsRemoveScb+0x61
fffff880`04b9a9e0 fffff880`016be4dc : fffff8a0`01bba010 fffff800`05e155a0 fffff880`04b9ab12 fffffa80`06f56830 :
Ntfs!NtfsPrepareFcbForRemoval+0x50
fffff880`04b9aa10 fffff880`01641ce2 : fffffa80`06f56830 fffffa80`06f56830 fffff8a0`01bba010 00000000`00000000 :
Ntfs!NtfsTeardownStructures+0xdc
fffff880`04b9aa90 fffff880`016d5773 : fffffa80`06f56830 fffff800`05e155a0 fffff8a0`01bba010 00000000`00000009 :
Ntfs!NtfsDecrementCloseCounts+0xa2
fffff880`04b9aad0 fffff880`016afde7 : fffffa80`06f56830 fffff8a0`01bba140 fffff8a0`01bba010 fffffa80`05a5e180 :
Ntfs!NtfsCommonClose+0x353
fffff880`04b9aba0 fffff800`05c7db21 : 00000000`00000000 fffff880`016afc00 fffff800`05e77101 00000000`00000002 :
Ntfs!NtfsFspClose+0x15f
fffff880`04b9ac70 fffff800`05f0f47a : 00000000`00000000 fffffa80`0402e1a0 00000000`00000080 fffffa80`03ffc990 :
nt!ExpWorkerThread+0x111
fffff880`04b9ad00 fffff800`05c4eda6 : fffff880`04964180 fffffa80`0402e1a0 fffff880`0496efc0 00000000`00000000 :
nt!PspSystemThreadStartup+0x5a
fffff880`04b9ad40 00000000`00000000 : fffff880`04b9b000 fffff880`04b95000 fffff880`04b9a9b0 00000000`00000000 :
nt!KiStartSystemThread+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!ExAcquireResourceExclusiveLite+54
fffff800`05c78a64 f0480fba696000 lock bts qword ptr [rcx+60h],0
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: nt!ExAcquireResourceExclusiveLite+54
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 5147dc36
FAILURE_BUCKET_ID: X64_0x50_nt!ExAcquireResourceExclusiveLite+54
BUCKET_ID: X64_0x50_nt!ExAcquireResourceExclusiveLite+54
Followup: MachineOwner
Re: [求助]文件系统BSOD原因分析
gfang
2014-01-06, 15:36 下午
问题的奇怪之处在于：文件是在我们文件系统的两个卷之间拷贝，但栈回溯里却显示跟NTFS有关，我再手工回溯调用栈试试。
另外尝试访问的内存有以下信息：
1: kd> !pool fffff88004bbe0b8
Pool page fffff88004bbe0b8 region is Unknown
fffff88004bbe000 is not a valid large pool allocation, checking large session pool...
fffff88004bbe000 is not a valid small pool allocation, checking large pool...
unable to get pool big page table - either wrong symbols or pool tagging is disabled
fffff88004bbe000 is freed (or corrupt) pool
Bad allocation size @fffff88004bbe000, too large
***
*** An error (or corruption) in the pool was detected;
*** Pool Region unknown (0xFFFFF88004BBE000)
***
*** Use !poolval fffff88004bbe000 for more details.
***
1: kd> !poolval fffff88004bbe0b8
Pool page fffff88004bbe0b8 region is Unknown
Validating Pool headers for pool page: fffff88004bbe0b8
Pool page [ fffff88004bbe000 ] is __inVALID.
Analyzing linked list...
Scanning for single bit errors...
None found