Hi All,
We have developed a encryption minifilter driver. It works successfully on NTFS drive but when we move to FAT32, we are facing a BSOD when we do some operation(No Fix set of Steps).
Call stack in dump is not pointing at our code straight away although I know its our driver. I am not able to pick anything from the BugCheck analysis by which I can relate it with our driver. Can any one help by suggesting something to start with.
Following is the text from windbg.
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
FAT_FILE_SYSTEM (23)
If you see FatExceptionFilter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative stack
trace.
Arguments:
Arg1: 000e0100
Arg2: aa8ff524
Arg3: aa8ff220
Arg4: aad38194
Debugging Details:
Exception 0xc0000005 while accessing file mapping
…
…-do-…
…
Exception 0xc0000005 while accessing file mapping
EXCEPTION_RECORD: aa8ff524 – (.exr ffffffffaa8ff524)
ExceptionAddress: aad38194 (Fastfat!FatFlushDirectory+0x0000010c)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 0000001c
Attempt to read from address 0000001c
CONTEXT: aa8ff220 – (.cxr ffffffffaa8ff220)
eax=00000000 ebx=861ae118 ecx=00000000 edx=85dcd5b8 esi=8620ef50 edi=e28fb008
eip=aad38194 esp=aa8ff5ec ebp=aa8ff630 iopl=0 nv up ei pl zr na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
Fastfat!FatFlushDirectory+0x10c:
aad38194 39411c cmp [ecx+0x1c],eax ds:0023:0000001c=???
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.
READ_ADDRESS: 0000001c
BUGCHECK_STR: 0x23
DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
LAST_CONTROL_TRANSFER: from aad38356 to aad38194
STACK_TEXT:
aa8ff630 aad38356 8620ef50 861e3408 00000001 Fastfat!FatFlushDirectory+0x10c
aa8ff64c aad2e13c 8620ef50 861ae118 00000001 Fastfat!FatFlushVolume+0x24
aa8ff69c aad26ae3 8620ef50 85dcd5b8 861ae118 Fastfat!FatOpenVolume+0xc7
aa8ff8e4 aad24ce0 8620ef50 85ab0008 aa8f0000 Fastfat!FatCommonCreate+0x3c0
aa8ff928 804e13d9 861ae020 85ab0008 85dcd5b8 Fastfat!FatFsdCreate+0x52
aa8ff938 f7523876 00000000 863533b0 85b5b318 nt!IopfCallDriver+0x31
aa8ff984 804e13d9 861b2958 00000001 85ab0008 sr!SrCreate+0x150
aa8ff994 f7533e9b 00000000 85ab0008 85ab0198 nt!IopfCallDriver+0x31
aa8ff9b8 f7540448 aa8ff9d8 860ce600 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
aa8ff9f4 804e13d9 860ce600 85ab0008 85ab0198 fltMgr!FltpCreate+0x26a
aa8ffa04 aab80f6f 85ab0018 860b12c0 85dcd5b8 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be wrong.
aa8ffa70 804e13d9 85dd4c70 85ab0008 85ab0008 ino_fltr+0xff6f
aa8ffa80 8057cc89 8636b8e8 85ace9c4 aa8ffc18 nt!IopfCallDriver+0x31
aa8ffb60 8056c063 8636b900 00000000 85ace920 nt!IopParseDevice+0xa12
aa8ffbd8 8056f2a8 00000000 aa8ffc18 00000040 nt!ObpLookupObjectName+0x53c
aa8ffc2c 8057d2e2 00000000 00000000 00000001 nt!ObOpenObjectByName+0xea
aa8ffca8 8057d3b1 00a5e3a4 00100001 00a5e374 nt!IopCreateFile+0x407
aa8ffd04 8057d55f 00a5e3a4 00100001 00a5e374 nt!IoCreateFile+0x8e
aa8ffd44 804dd99f 00a5e3a4 00100001 00a5e374 nt!NtOpenFile+0x27
aa8ffd44 7c90eb94 00a5e3a4 00100001 00a5e374 nt!KiFastCallEntry+0xfc
00a5e3bc 00000000 00000000 00000000 00000000 0x7c90eb94
FOLLOWUP_IP:
Fastfat!FatFlushDirectory+10c
aad38194 39411c cmp [ecx+0x1c],eax
Thanks
Aditya
I have tried several command mentioned at url http://www.osronline.com/article.cfm?id=49.
-
kbvs command is not working, WinDbg always responds "Couldn’t resolve error at ‘vs’ ".
Any one suggest what it coult be. as kb is working fine.
-
I have reached to a more descriptive stack trace, although still not able to relate it to our minifilter driver directly but it seems that our driver may be involved between these two calls of call stack.
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b (FPO: [Non-Fpo])
/*Our driver could be at this place which do some thing bad to make this call crash later*/
b929e9f4 804ef095 8980aee8 88ff96a8 88ff9838 fltMgr!FltpCreate+0x26a (FPO: [Non-Fpo])
Is it possible to track something more usefull from the following trace.
/****************************************************************/
ChildEBP RetAddr Args to Child
b929dbd0 804f8cb1 00000003 b929df2c 00000000 nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
b929dc1c 804f989c 00000003 c0000005 896b58a0 nt!KiBugCheckDebugBreak+0x19 (FPO: [Non-Fpo])
b929dffc 804f9deb 00000023 000e0100 b929e524 nt!KeBugCheck2+0x574 (FPO: [Non-Fpo])
b929e01c ba056a4f 00000023 000e0100 b929e524 nt!KeBugCheckEx+0x1b (FPO: [Non-Fpo])
b929e044 ba05dd01 896b58a0 b929e070 80538d61 Fastfat!FatExceptionFilter+0x92 (FPO: [Non-Fpo])
b929e050 80538d61 b929e078 00000000 b929e078 Fastfat!FatFsdCreate+0x6e (FPO: [Non-Fpo])
b929e078 8054604e b929e524 b929e918 b929e220 nt!_except_handler3+0x61 (FPO: [Uses EBP] [3,0,7])
b929e09c 80546020 b929e524 b929e918 b929e220 nt!ExecuteHandler2+0x26
b929e14c 804fe448 b929e524 b929e220 0000001c nt!ExecuteHandler+0x24
b929e508 805412d5 b929e524 00000000 b929e578 nt!KiDispatchException+0x13e (FPO: [Non-Fpo])
b929e570 80541286 b929e630 ba071194 badb0d00 nt!CommonDispatchException+0x4d (FPO: [0,20,0])
b929e584 ba05f6f0 ba05ea2f 896b58a0 e1ef6220 nt!Kei386EoiHelper+0x18a
b929e630 ba071356 896b58a0 898b5320 00000001 Fastfat!FatOpenDirectoryFile+0x117 (FPO: [Non-Fpo])
b929e64c ba06713c 896b58a0 898b4c28 00000001 Fastfat!FatFlushVolume+0x24 (FPO: [Non-Fpo])
b929e69c ba05fae3 896b58a0 8955d868 898b4c28 Fastfat!FatOpenVolume+0xc7 (FPO: [Non-Fpo])
b929e8e4 ba05dce0 896b58a0 88ff96a8 b9290000 Fastfat!FatCommonCreate+0x3c0 (FPO: [Non-Fpo])
b929e928 804ef095 898b4b30 88ff96a8 8955d868 Fastfat!FatFsdCreate+0x52 (FPO: [Non-Fpo])
b929e938 ba6de876 00000000 89bd1f38 8959ef00 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
b929e984 804ef095 89aa59b8 00000001 88ff96a8 sr!SrCreate+0x150 (FPO: [Non-Fpo])
b929e994 ba6eee9b 00000000 88ff96a8 88ff9838 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
b929e9b8 ba6fb448 b929e9d8 8980aee8 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b (FPO: [Non-Fpo])
b929e9f4 804ef095 8980aee8 88ff96a8 88ff9838 fltMgr!FltpCreate+0x26a (FPO: [Non-Fpo])
b929ea04 b9cb9f6f 88ff96b8 897f8ac0 8955d868 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
WARNING: Stack unwind information not available. Following frames may be wrong.
b929ea70 804ef095 89628020 88ff96a8 88ff96a8 ino_fltr+0xff6f
b929ea80 80581f6e 89c3a350 88fe8264 b929ec18 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
b929eb60 805bddc0 89c3a368 00000000 88fe81c0 nt!IopParseDevice+0xa12 (FPO: [Non-Fpo])
b929ebd8 805ba448 00000000 b929ec18 00000040 nt!ObpLookupObjectName+0x53c (FPO: [Non-Fpo])
b929ec2c 80574ec1 00000000 00000000 00000001 nt!ObOpenObjectByName+0xea (FPO: [Non-Fpo])
b929eca8 80575838 0099e3a4 00100001 0099e374 nt!IopCreateFile+0x407 (FPO: [Non-Fpo])
b929ed04 80578ff7 0099e3a4 00100001 0099e374 nt!IoCreateFile+0x8e (FPO: [Non-Fpo])
b929ed44 8054086c 0099e3a4 00100001 0099e374 nt!NtOpenFile+0x27 (FPO: [Non-Fpo])
b929ed44 7c90eb94 0099e3a4 00100001 0099e374 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ b929ed64)
0099e344 7c90dd09 7166dad5 0099e3a4 00100001 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
0099e348 7166dad5 0099e3a4 00100001 0099e374 ntdll!NtOpenFile+0xc (FPO: [6,0,0])
0099e3bc 7166e4a8 0099e3e8 0099e413 7173d790 cimwin32!LogicalDisk::IsVolumeDirty+0x76 (FPO: [Non-Fpo])
0099ec50 7166eb84 008823f0 0099eca0 7173d790 cimwin32!LogicalDisk::GetDriveVolumeInformation+0x34f (FPO: [Non-Fpo])
0099ec78 7166f2ab 008823f0 0099eca0 ffffffff cimwin32!LogicalDisk::GetFixedDriveInfo+0x60 (FPO: [Non-Fpo])
0099ecc4 7166f9f7 008823f0 ffffffff 00000111 cimwin32!LogicalDisk::GetLogicalDiskInfo+0xd4 (FPO: [Non-Fpo])
0099ef98 692cb26d 00882e28 00000000 00882e28 cimwin32!LogicalDisk::EnumerateInstances+0x186 (FPO: [Non-Fpo])
0099efac 692cfa21 00882e28 00000000 000c5188 framedyn!Provider::CreateInstanceEnum+0x21 (FPO: [Non-Fpo])
/****************************************************************/
I don’t think that ‘kbvs’ is not a valid WinDbg command, or at least isn’t documented as such at this point; I assume that it used to be, as that article is almost eight years old. I don’t think that the documentation is exactly correct either, as it reads as if you can’t combine commands, which you can. That is, it says ‘k[b|p|P|v]’, which, as I read it, would mean that something like ‘kvb’ is invalid, which is incorrect, at least on 6.7.5.1. Curiously, however, ‘kbv’ fails, so maybe permuting ‘kbvs’ might work, but it doesn’t appear so as ‘s’ isn’t in the documentation at all. ‘kvbp’ produces the most information, and essentially what is available in the Call Stack Widnow, I believe, but if you don’t have full symbols, what it produces looks like an error, because it goes on for so long that you lose the first part of the data.
Good luck,
mm