Bugcheck 0x7f DOUBLE_FAULT

Hi,

I have encountered a 0x7f double_fault crash due to stack overflow. Following are the details and the questions I have to ask:

The binaries seen on the stack are:

FSFD = our filter driver
ikit = 3rd party filter driver
vkit = 3rd party filter driver
idll = 3rd party dll

The file system device stack is (top to bottom):

ikit
FSFD
Ntfs

Machine and symbol information:

Symbol search path is: srv*E:\symbols*Symbol information
Executable search path is:
Windows 2000 Kernel Version 2195 (Service Pack 4) MP (4 procs) Free x86 compatible
Product: LanManNt, suite: TerminalServer SingleUserTS
Kernel base = 0x80400000 PsLoadedModuleList = 0x80485b40

kd> !analyze -v

UNEXPECTED_KERNEL_MODE_TRAP (7f)
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0x7f_8

TSS: 00000028 -- (.tss 28)
eax=bdbe008c ebx=85d01a14 ecx=88f1b4d0 edx=85d018a8 esi=85d018a8 edi=88b17300
eip=bfe9a278 esp=bdbdffa8 ebp=bdbe0028 iopl=0 nv up ei ng nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010292
Ntfs!NtfsFsdRead+0x22:
bfe9a278 53 push ebx
Resetting default scope

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO
PROCESS_NAME: sampleexecutable.exe
LAST_CONTROL_TRANSFER: from 8041eec9 to bfe9a278
STACK_TEXT:
bdbe0028 8041eec9 88b17300 85d018a8 85d01a38 Ntfs!NtfsFsdRead+0x22
bdbe003c beda9df0 88a99aa0 85d018a8 bdbe009c nt!IopfCallDriver+0x35
WARNING: Stack unwind information not available. Following frames may be wrong.
bdbe0050 beda9968 88a99aa0 85d018a8 88a99aa0 FSFD+0xddf0
00000000 00000000 00000000 00000000 00000000 FSFD+0xd968

STACK_COMMAND: .tss 0x28 ; kb

FOLLOWUP_IP:
FSFD+ddf0
beda9df0 5f pop edi

SYMBOL_STACK_INDEX: 2
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: FSFD
IMAGE_NAME: FSFD.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 44d9774a
SYMBOL_NAME: FSFD+ddf0
FAILURE_BUCKET_ID: 0x7f_8_FSFD+ddf0
BUCKET_ID: 0x7f_8_FSFD+ddf0
Followup: MachineOwner

0: kd> !thread
THREAD 880338a0 Cid 6c8.d14 Teb: 7ff95000 Win32Thread: 00000000 RUNNING
IRP List:
869b6008: (0006,01b4) Flags: 00000884 Mdl: 00000000
86740008: (0006,01b4) Flags: 00000884 Mdl: 00000000
Impersonation token: e5c12670 (Level Delegation)
Owning Process 88432020
Wait Start TickCount 41589205 Elapsed Ticks: 0
Context Switch Count 45815
UserTime 0:00:38.0609
KernelTime 0:00:08.0828
Start Address KERNEL32!BaseThreadStartThunk (0x7c57b710)
Win32 Start Address idll (0x66241838)
Stack Init bdbe3000 Current bdbe2ca0 Base bdbe3000 Limit bdbe0000 Call 0
Priority 14 BasePriority 13 PriorityDecrement 0 DecrementCount 0

The stack after the placing the correct symbols for FSFD.sys is:

0: kd> kb 100
ChildEBP RetAddr Args to Child
00000000 bfe9a278 00000000 00000000 00000000 nt!KiTrap08+0x41
bdbe0028 8041eec9 88b17300 85d018a8 85d01a38 Ntfs!NtfsFsdRead+0x22
bdbe003c beda9df0 88a99aa0 85d018a8 bdbe009c nt!IopfCallDriver+0x35
bdbe0050 beda9968 88a99aa0 85d018a8 88a99aa0 FSFD!Dispatch+0x50
bdbe009c beda07d4 88a99aa0 85d018a8 beda0840 FSFD!DispatchWrapper+0x158
bdbe00b8 8041eec9 88a99aa0 85d018a8 85d018a8 FSFD!Read+0x21
bdbe00cc bdc5a426 8825d960 bdbe0170 8825d960 nt!IopfCallDriver+0x35
WARNING: Stack unwind information not available. Following frames may be wrong.
bdbe0150 bdc67bd9 88ee3498 85d018a8 bdbe0188 ikit+0x7426
bdbe0160 bdc67c29 bdbe0170 85d018a8 8825d960 ikit+0x14bd9
bdbe0188 8041eec9 8825d960 85d018a8 88ee3498 ikit!Dispatch+0x48

bdbe019c 8042028b 00000000 00000000 87938628 nt!IopfCallDriver+0x35
bdbe01b0 80443838 88ee3498 87938660 87938640 nt!IoPageRead+0xb1
bdbe01ec 8044c6b6 00000000 d4b58400 c0352d60 nt!MiDispatchFault+0x24c
bdbe023c 8046b053 00000000 00000000 00000000 nt!MmAccessFault+0x704 < Second Fault
bdbe023c 804120e3 00000000 00000000 00000000 nt!KiTrap0E+0xc7
bdbe030c bfead661 88ee3498 bdbe0340 00000400 nt!CcMapData+0xd9
bdbe0330 bfead721 87216c88 88b19c08 009d8400 Ntfs!NtfsMapStream+0x4d
bdbe03a8 bfeada5e 87216c88 88b173d0 cbb42598 Ntfs!NtfsReadMftRecord+0xa5
bdbe03dc bfed2757 87216c88 88b173d0 cbb40002 Ntfs!NtfsReadFileRecord+0x8e
bdbe0434 bfeadeac 87216c88 e15d1bc8 000000a0 Ntfs!NtfsLookupExternalAttribute+0x26f
bdbe0478 bfe96220 87216c88 e15d1bc8 cbb42490 Ntfs!NtfsLookupInFileRecord+0x21e
bdbe0588 bfea005e 87216c88 e15d7e48 00000007 Ntfs!NtfsLookupAllocation+0xd2
bdbe0758 bfe9687f 87216c88 87022008 e15d7e48 Ntfs!NtfsPrepareBuffers+0x25e
bdbe092c bfe9b424 87216c88 87022008 e15d7e48 Ntfs!NtfsNonCachedIo+0x121
bdbe0b44 bfe9a3ba 87216c88 87022008 00000001 Ntfs!NtfsCommonRead+0xeee
bdbe0be4 8041eec9 88b17300 87022008 87022198 Ntfs!NtfsFsdRead+0x164
bdbe0bf8 beda9df0 88a99aa0 87022008 bdbe0c58 nt!IopfCallDriver+0x35
bdbe0c0c beda9968 88a99aa0 87022008 88a99aa0 FSFD!Dispatch+0x50
bdbe0c58 beda07d4 88a99aa0 87022008 beda0840 FSFD!DispatchWrapper+0x158
bdbe0c74 8041eec9 88a99aa0 87022008 87022008 FSFD!Read+0x21
bdbe0c88 bdc5a426 8825d960 bdbe0d2c 8825d960 nt!IopfCallDriver+0x35
bdbe0d0c bdc67bd9 88b15478 87022008 bdbe0d44 ikit+0x7426
bdbe0d1c bdc67c29 bdbe0d2c 87022008 8825d960 ikit+0x14bd9
bdbe0d44 8041eec9 8825d960 87022008 88b15478 ikit!Dispatch+0x48

bdbe0d58 8042028b 00000000 00000000 86a61d88 nt!IopfCallDriver+0x35
bdbe0d6c 80443838 88b15478 86a61dc0 86a61da0 nt!IoPageRead+0xb1
bdbe0da8 8044c6b6 00000000 d9bc7000 c0366f1c nt!MiDispatchFault+0x24c
bdbe0df8 8046b053 00000000 00000000 00000000 nt!MmAccessFault+0x704 < First Fault
bdbe0df8 804120e3 00000000 00000000 00000000 nt!KiTrap0E+0xc7
bdbe0ec8 bfead661 88b15478 bdbe0efc 00001000 nt!CcMapData+0xd9
bdbe0eec bfeaf465 87786488 e15d7e48 00007000 Ntfs!NtfsMapStream+0x4d
bdbe0f1c bfeaf926 87786488 0000000c 00000007 Ntfs!ReadIndexBuffer+0x8b
bdbe0f48 bff056ff 87786488 bdbe0fcc bdbe10bc Ntfs!FindFirstIndexEntry+0x1be
bdbe1054 bfefe26a 87786488 e15d7e48 bdbe10bc Ntfs!NtOfsFindRecord+0xbd
bdbe10c4 bfefe072 87786488 88b173d0 000001d6 Ntfs!MapSecurityIdToSecurityDescriptorHeaderUnsafe+0x32
bdbe1118 bfefe35a 87786488 88b173d0 000001d6 Ntfs!NtfsCacheSharedSecurityBySecurityId+0xb6
bdbe1190 bfeae2f9 87786488 e2a0a008 bdbe1cd8 Ntfs!NtfsLoadSecurityDescriptor+0x46
bdbe1280 bfeb029a 87786488 e2a0a008 e46c8008 Ntfs!NtfsAccessCheck+0x59
bdbe12b0 bfeb00ab 87786488 869b6150 e2a0a2f8 Ntfs!NtfsCheckExistingFile+0x80
bdbe12d8 bfeb0494 87786488 869b6008 869b6150 Ntfs!NtfsOpenExistingAttr+0x21
bdbe13e8 bfedaf1d 87786488 869b6008 869b6150 Ntfs!NtfsOpenAttributeInExistingFile+0x1ae
bdbe14f4 bfed9ee7 87786488 869b6008 869b6150 Ntfs!NtfsOpenExistingPrefixFcb+0x339
bdbe1814 bfeaa666 87786488 869b6008 bdbe1888 Ntfs!NtfsCommonCreate+0x17f7
bdbe18c8 8041eec9 88b17300 869b6008 869b6174 Ntfs!NtfsFsdCreate+0x186
bdbe18dc beda9df0 88a99aa0 869b6008 bdbe193c nt!IopfCallDriver+0x35
bdbe18f0 beda9968 88a99aa0 869b6008 88a99aa0 FSFD!Dispatch+0x50
bdbe193c bed9dd40 88a99aa0 869b6008 bed9e58c FSFD!DispatchWrapper+0x158
bdbe1954 8041eec9 88a99aa0 869b6008 869b6198 FSFD!Create+0x1b
bdbe1968 bdc68990 879e6424 879e63c8 00000002 nt!IopfCallDriver+0x35
bdbe1990 bdc59d1d 869b6008 bdbe1a44 869b6008 ikit!FilteredDevicePass+0x48
bdbe19b4 bdc5a38e 869b6008 869b6198 852659e8 ikit+0x6d1d
bdbe1a4c bdc67bd9 852659e8 869b6008 bdbe1a84 ikit+0x738e
bdbe1a5c bdc67c29 bdbe1a6c 869b6008 8825d960 ikit+0x14bd9
bdbe1a84 8041eec9 8825d960 869b6008 869b6018 ikit!Dispatch+0x48

bdbe1a98 804c4412 80486b60 804c395a bdbe1d94 nt!IopfCallDriver+0x35
bdbe1c20 804535cc 88f297b0 00000000 bdbe1cd8 nt!IopParseDevice+0xab8
bdbe1c98 804da492 00000000 89051a00 00000040 nt!ObpLookupObjectName+0x504
bdbe1da8 804a444f 00000000 00000000 00000000 nt!ObOpenObjectByName+0xc8
bdbe1e84 804a3ff4 bdbe2034 00000080 bdbe1fd8 nt!IopCreateFile+0x407
bdbe1ecc 804acd87 bdbe2034 00000080 bdbe1fd8 nt!IoCreateFile+0x36
bdbe1f0c 80468379 bdbe2034 00000080 bdbe1fd8 nt!NtOpenFile+0x25
bdbe1f0c 80431ac7 bdbe2034 00000080 bdbe1fd8 nt!KiSystemService+0xc9
bdbe1f9c bedb44cc bdbe2034 00000080 bdbe1fd8 nt!ZwOpenFile+0xb
bdbe202c bed9f9dc 88a99b74 e3086bc8 00000000 FSFD!Fn6+0xac
bdbe2088 bed9f6c9 88a99b74 e25eaef0 00000000 FSFD!Fn5+0x8c
bdbe20fc bed9f414 88a99b58 88a9bdd0 e25e3f04 FSFD!Fn4+0x119
bdbe218c bed9ecbd 88a99b58 88a9bdd0 e25e3f04 FSFD!Fn3+0x324
bdbe223c bed9e930 88a99aa0 86740008 88a9bdd0 FSFD!Fn2+0x19d
bdbe2274 beda98eb 88a99aa0 86740008 88a9bd00 FSFD!Fn1+0x3a4
bdbe22c4 bed9dd40 88a99aa0 86740008 bed9e58c FSFD!DispatchWrapper+0xdb
bdbe22dc 8041eec9 88a99aa0 86740008 86740198 FSFD!Create+0x1b
bdbe22f0 bdc57e94 8825db88 86740198 86740008 nt!IopfCallDriver+0x35
bdbe233c bdc5a271 8825d960 871fa228 88a99aa0 ikit+0x4e94
bdbe23d0 bdc67bd9 88336028 86740008 bdbe2408 ikit+0x7271
bdbe23e0 bdc67c29 bdbe23f0 86740008 8825d960 ikit+0x14bd9
bdbe2408 8041eec9 8825d960 86740008 86740018 ikit!Dispatch+0x48

bdbe241c 804c4412 80486b60 804c395a bdbe2718 nt!IopfCallDriver+0x35
bdbe25a4 804535cc 88f297b0 00000000 bdbe265c nt!IopParseDevice+0xab8
bdbe261c 804da492 00000000 89051a00 00000040 nt!ObpLookupObjectName+0x504
bdbe272c 804a444f 00000000 00000000 88e75300 nt!ObOpenObjectByName+0xc8
bdbe2808 804a3ff4 bdbe2a5c 001f01ff bdbe2974 nt!IopCreateFile+0x407
bdbe2850 804abafc bdbe2a5c 001f01ff bdbe2974 nt!IoCreateFile+0x36
bdbe2890 80468379 bdbe2a5c 001f01ff bdbe2974 nt!NtCreateFile+0x2e
bdbe2890 80431693 bdbe2a5c 001f01ff bdbe2974 nt!KiSystemService+0xc9
bdbe2934 bdc5d9ce bdbe2a5c 001f01ff bdbe2974 nt!ZwCreateFile+0xb
bdbe29c0 bdc5d5ef 00000000 00000000 bdbe2b34 ikit+0xa9ce
bdbe2a18 bde16fbe 00000000 00000000 00000017 ikit+0xa5ef
bdbe2a68 bde176a3 00000000 bdbe2b34 88248248 vkit+0x3fbe
bdbe2a90 bdc552a3 bd3544cc 00000001 bdbe2b14 vkit+0x46a3
bdbe2ac8 bdc55891 00000301 bdbe2b14 000000b0 ikit+0x22a3
bdbe2be0 bdc681c6 88298848 bdbe2c01 00d65cb8 ikit+0x2891
bdbe2c20 804b3de9 88298848 00000001 00d65cb8 ikit!Dispatch+0x5e5
bdbe2d00 804abd0a 000002c8 00000000 00000000 nt!IopXxxControlFile+0x2e1
bdbe2d34 80468379 000002c8 00000000 00000000 nt!NtDeviceIoControlFile+0x28
bdbe2d34 77f88403 000002c8 00000000 00000000 nt!KiSystemService+0xc9

The crash occured due to stack overflow as the current value for esp (bdbdffa8) is
below the thread stack limit (bdbe0000). Looking at the stack, we can see that there is no driver which uses an unusally large amount of stack space and which can be held responsible for the crash.

We can see a page fault occuring while servicing a page fault. I searched on google, on osronline and a few books and encountered conflicting pieces of information about chained page faults. Could you please inform if it is proper to have such page faults?

The flow entered the kernel mode to service the IOCTL passed by the usermode process.
Is it allowed to operate on files (call ZwCreateFile and other operations) while running in the context of a dispatch routine (IOCTL dispatch, in this case)?

Thanks for your help,
Amol

> The crash occured due to stack overflow as the current value for esp
(bdbdffa8)

is
below the thread stack limit (bdbe0000). Looking at the stack, we can see
that

Double faults cannot be handled except by BSOD.

So, reducing the stack usage of your driver is the only way - move all auto
declated structures to pool allocations etc.

And yes, Windows can be crashed by installing too many filter drivers. This is
normal.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Wow. Can I have this dump for debug class? What a nice stack overflow (take device control, add an IRP_MJ_CREATE inside of it, a second one (just for good measure) and then a couple of paging reads to get some NTFS meta-data and you have a GREAT stack overflow.)

I think Max is overly optimistic in his belief you can help by decreasing your stack footprint - I think you need to seriously rethink opening the file in device control or in running in a system with four legacy filters installed.

Best bet is to convert to mini-filter.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Thanks Maxim, thanks Tony, thanks for the comments. I see that the operations seen on the stack are all correct but because of the number of operations and the behavior of calling ZwCreateFile from within DispatchRoutine, the overflow was caused.

About the stack usage, I calculated the stack usage by each function call seen on the stack and found the following information:
nt 3820 bytes
Ntfs 4984 bytes
ikit+ vkit 1688 bytes
FSFD 1200 bytes

Tony, windbg shows the detailed stack only when the symbols for FSFD.sys are placed. I am not in a position to provide those symbols. I am so sorry.

Kind regards,
Amol