fltMgr!CreateTemporaryFileNameInformation crash in IOStress

NTFSD
1

A new version of my driver is crashing in IOStress with the mess below after
running 30 minutes or so. fltMgr!CreateTemporaryFileNameInformation is
running when it crashes. Can someone tell me what might cause this so I can
figure out where to look for problems in my code? I only call
CreateTemporaryFileNameInformation in one place, but I haven't changed
anything in that area of code.

kd> !analyze -v
... * Bugcheck Analysis * ...

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 80042000
Arg3: 00000000
Arg4: 00000000
Debugging Details:

BUGCHECK_STR: 0x7f_8
TSS: 00000028 -- (.tss 28)
eax=0000bb40 ebx=f9c65478 ecx=00000000 edx=00000000 esi=f9c65424
edi=536a2c84
eip=80824e3c esp=f9c64fbc ebp=f9c65048 iopl=0 nv up ei ng nz ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010292
nt!KeContextFromKframes+0x10:
80824e3c 53 push ebx
Resetting default scope
DEFAULT_BUCKET_ID: DRIVER_FAULT
LAST_CONTROL_TRANSFER: from 80855793 to 80855712
STACK_TEXT:
f9c65f54 80855793 7123642c 00000000 f9c663a8 nt!RtlIsValidHandler+0x3c
f9c65fd0 80825700 f9c663a8 f9c660a4 536a2c84 nt!RtlDispatchException+0x59
f9c6638c 80866251 f9c663a8 00000000 f9c663fc nt!KiDispatchException+0x13e
f9c663f4 80866202 f9c66480 80855712 badb0d00 nt!CommonDispatchException+0x4d
f9c66480 80855793 7123642c 00000000 f9c668d4 nt!Kei386EoiHelper+0x18a
f9c664fc 80825700 f9c668d4 f9c665d0 536a2c84 nt!RtlDispatchException+0x59
f9c668b8 80866251 f9c668d4 00000000 f9c66928 nt!KiDispatchException+0x13e
f9c66920 80866202 f9c669ac 80855712 badb0d00 nt!CommonDispatchException+0x4d
f9c669ac 80855793 7123642c 00000000 f9c66e00 nt!Kei386EoiHelper+0x18a
f9c66a28 80825700 f9c66e00 f9c66afc 1a60160f nt!RtlDispatchException+0x59
f9c66de4 80866251 f9c66e00 00000000 f9c66e54 nt!KiDispatchException+0x13e
f9c66e4c 80866202 f9c67dac bae1c80c badb0d00 nt!CommonDispatchException+0x4d
f9c66e64 bae587a9 f9c66e7c 8085fcbb f9c60068 nt!Kei386EoiHelper+0x18a
f9c66e74 00000000 f9c66e94 bae1b9d2 00000000
fltMgr!CreateTemporaryFileNameInformation+0xf

MODULE_NAME: nt
IMAGE_NAME: ntkrnlpa.exe
FOLLOWUP_NAME: MachineOwner
DEBUG_FLR_IMAGE_TIMESTAMP: 41107b0c
FOLLOWUP_IP:
nt!KeContextFromKframes+10
80824e3c 53 push ebx
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: nt!KeContextFromKframes+10
STACK_COMMAND: .tss 28 ; kb
FAILURE_BUCKET_ID: TRAP_FRAME_RECURSION
BUCKET_ID: TRAP_FRAME_RECURSION
Followup: MachineOwner

2

This is a stack overflow; it appears to occur when you are handling an
exception; the exception handler then appears to create an additional
exception, and so forth.

Try setting the stack backtrace size much larger (".kframes 100" should
do it) and getting the full stack trace. Then you should be able to see
the call sequence back up into your driver.

Bottom line: this is a secondary failure; the primary failure is the
initial exception cause. Trying to figure out the secondary failure is
likely to be rather interesting but quite time consuming. If you fix
the primary failure, though, then you won't need to track down the
secondary failure.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.

Looking forward to seeing you at the next OSR File Systems class in Los
Angeles, CA October 24-27, 2005.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Thursday, September 15, 2005 10:18 PM
To: ntfsd redirect
Subject: [ntfsd] fltMgr!CreateTemporaryFileNameInformation crash in
IOStress

A new version of my driver is crashing in IOStress with the mess below
after
running 30 minutes or so. fltMgr!CreateTemporaryFileNameInformation is
running when it crashes. Can someone tell me what might cause this so I
can
figure out where to look for problems in my code? I only call
CreateTemporaryFileNameInformation in one place, but I haven't changed
anything in that area of code.

kd> !analyze -v
... * Bugcheck Analysis * ...

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 80042000
Arg3: 00000000
Arg4: 00000000
Debugging Details:

BUGCHECK_STR: 0x7f_8
TSS: 00000028 -- (.tss 28)
eax=0000bb40 ebx=f9c65478 ecx=00000000 edx=00000000 esi=f9c65424
edi=536a2c84
eip=80824e3c esp=f9c64fbc ebp=f9c65048 iopl=0 nv up ei ng nz ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010292
nt!KeContextFromKframes+0x10:
80824e3c 53 push ebx
Resetting default scope
DEFAULT_BUCKET_ID: DRIVER_FAULT
LAST_CONTROL_TRANSFER: from 80855793 to 80855712
STACK_TEXT:
f9c65f54 80855793 7123642c 00000000 f9c663a8 nt!RtlIsValidHandler+0x3c
f9c65fd0 80825700 f9c663a8 f9c660a4 536a2c84
nt!RtlDispatchException+0x59
f9c6638c 80866251 f9c663a8 00000000 f9c663fc
nt!KiDispatchException+0x13e
f9c663f4 80866202 f9c66480 80855712 badb0d00
nt!CommonDispatchException+0x4d
f9c66480 80855793 7123642c 00000000 f9c668d4 nt!Kei386EoiHelper+0x18a
f9c664fc 80825700 f9c668d4 f9c665d0 536a2c84
nt!RtlDispatchException+0x59
f9c668b8 80866251 f9c668d4 00000000 f9c66928
nt!KiDispatchException+0x13e
f9c66920 80866202 f9c669ac 80855712 badb0d00
nt!CommonDispatchException+0x4d
f9c669ac 80855793 7123642c 00000000 f9c66e00 nt!Kei386EoiHelper+0x18a
f9c66a28 80825700 f9c66e00 f9c66afc 1a60160f
nt!RtlDispatchException+0x59
f9c66de4 80866251 f9c66e00 00000000 f9c66e54
nt!KiDispatchException+0x13e
f9c66e4c 80866202 f9c67dac bae1c80c badb0d00
nt!CommonDispatchException+0x4d
f9c66e64 bae587a9 f9c66e7c 8085fcbb f9c60068 nt!Kei386EoiHelper+0x18a
f9c66e74 00000000 f9c66e94 bae1b9d2 00000000
fltMgr!CreateTemporaryFileNameInformation+0xf

MODULE_NAME: nt
IMAGE_NAME: ntkrnlpa.exe
FOLLOWUP_NAME: MachineOwner
DEBUG_FLR_IMAGE_TIMESTAMP: 41107b0c
FOLLOWUP_IP:
nt!KeContextFromKframes+10
80824e3c 53 push ebx
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: nt!KeContextFromKframes+10
STACK_COMMAND: .tss 28 ; kb
FAILURE_BUCKET_ID: TRAP_FRAME_RECURSION
BUCKET_ID: TRAP_FRAME_RECURSION
Followup: MachineOwner

Questions? First check the IFS FAQ at

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

It look like stack overflow to me - double fault that is caused by pushing a
register to the stack.

Alexei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Hahn
Sent: Thursday, September 15, 2005 7:18 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] fltMgr!CreateTemporaryFileNameInformation crash in
IOStress

A new version of my driver is crashing in IOStress with the mess below after
running 30 minutes or so. fltMgr!CreateTemporaryFileNameInformation is
running when it crashes. Can someone tell me what might cause this so I can
figure out where to look for problems in my code? I only call
CreateTemporaryFileNameInformation in one place, but I haven't changed
anything in that area of code.

kd> !analyze -v
... * Bugcheck Analysis * ...

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 80042000
Arg3: 00000000
Arg4: 00000000
Debugging Details:

BUGCHECK_STR: 0x7f_8
TSS: 00000028 -- (.tss 28)
eax=0000bb40 ebx=f9c65478 ecx=00000000 edx=00000000 esi=f9c65424
edi=536a2c84
eip=80824e3c esp=f9c64fbc ebp=f9c65048 iopl=0 nv up ei ng nz ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010292
nt!KeContextFromKframes+0x10:
80824e3c 53 push ebx
Resetting default scope
DEFAULT_BUCKET_ID: DRIVER_FAULT
LAST_CONTROL_TRANSFER: from 80855793 to 80855712
STACK_TEXT:
f9c65f54 80855793 7123642c 00000000 f9c663a8 nt!RtlIsValidHandler+0x3c
f9c65fd0 80825700 f9c663a8 f9c660a4 536a2c84 nt!RtlDispatchException+0x59
f9c6638c 80866251 f9c663a8 00000000 f9c663fc nt!KiDispatchException+0x13e
f9c663f4 80866202 f9c66480 80855712 badb0d00 nt!CommonDispatchException+0x4d
f9c66480 80855793 7123642c 00000000 f9c668d4 nt!Kei386EoiHelper+0x18a
f9c664fc 80825700 f9c668d4 f9c665d0 536a2c84 nt!RtlDispatchException+0x59
f9c668b8 80866251 f9c668d4 00000000 f9c66928 nt!KiDispatchException+0x13e
f9c66920 80866202 f9c669ac 80855712 badb0d00 nt!CommonDispatchException+0x4d
f9c669ac 80855793 7123642c 00000000 f9c66e00 nt!Kei386EoiHelper+0x18a
f9c66a28 80825700 f9c66e00 f9c66afc 1a60160f nt!RtlDispatchException+0x59
f9c66de4 80866251 f9c66e00 00000000 f9c66e54 nt!KiDispatchException+0x13e
f9c66e4c 80866202 f9c67dac bae1c80c badb0d00 nt!CommonDispatchException+0x4d
f9c66e64 bae587a9 f9c66e7c 8085fcbb f9c60068 nt!Kei386EoiHelper+0x18a
f9c66e74 00000000 f9c66e94 bae1b9d2 00000000
fltMgr!CreateTemporaryFileNameInformation+0xf

MODULE_NAME: nt
IMAGE_NAME: ntkrnlpa.exe
FOLLOWUP_NAME: MachineOwner
DEBUG_FLR_IMAGE_TIMESTAMP: 41107b0c
FOLLOWUP_IP:
nt!KeContextFromKframes+10
80824e3c 53 push ebx
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: nt!KeContextFromKframes+10
STACK_COMMAND: .tss 28 ; kb
FAILURE_BUCKET_ID: TRAP_FRAME_RECURSION
BUCKET_ID: TRAP_FRAME_RECURSION
Followup: MachineOwner

Questions? First check the IFS FAQ at

You are currently subscribed to ntfsd as: xxxxx@vmware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Thanks to both of you. Hopefully I will learn how to read these myself
someday.

My new code does indeed stress the stack more so I’m sure I can fix it now.

“Alexei Jelvis” wrote in message news:xxxxx@ntfsd…
It look like stack overflow to me - double fault that is caused by pushing a
register to the stack.

Alexei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Hahn
Sent: Thursday, September 15, 2005 7:18 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] fltMgr!CreateTemporaryFileNameInformation crash in
IOStress

A new version of my driver is crashing in IOStress with the mess below after
running 30 minutes or so. fltMgr!CreateTemporaryFileNameInformation is
running when it crashes. Can someone tell me what might cause this so I can
figure out where to look for problems in my code? I only call
CreateTemporaryFileNameInformation in one place, but I haven’t changed
anything in that area of code.

kd> !analyze -v
… * Bugcheck Analysis * …

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a portion of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 80042000
Arg3: 00000000
Arg4: 00000000
Debugging Details:
------------------

BUGCHECK_STR: 0x7f_8
TSS: 00000028 – (.tss 28)
eax=0000bb40 ebx=f9c65478 ecx=00000000 edx=00000000 esi=f9c65424
edi=536a2c84
eip=80824e3c esp=f9c64fbc ebp=f9c65048 iopl=0 nv up ei ng nz ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010292
nt!KeContextFromKframes+0x10:
80824e3c 53 push ebx
Resetting default scope
DEFAULT_BUCKET_ID: DRIVER_FAULT
LAST_CONTROL_TRANSFER: from 80855793 to 80855712
STACK_TEXT:
f9c65f54 80855793 7123642c 00000000 f9c663a8 nt!RtlIsValidHandler+0x3c
f9c65fd0 80825700 f9c663a8 f9c660a4 536a2c84 nt!RtlDispatchException+0x59
f9c6638c 80866251 f9c663a8 00000000 f9c663fc nt!KiDispatchException+0x13e
f9c663f4 80866202 f9c66480 80855712 badb0d00 nt!CommonDispatchException+0x4d
f9c66480 80855793 7123642c 00000000 f9c668d4 nt!Kei386EoiHelper+0x18a
f9c664fc 80825700 f9c668d4 f9c665d0 536a2c84 nt!RtlDispatchException+0x59
f9c668b8 80866251 f9c668d4 00000000 f9c66928 nt!KiDispatchException+0x13e
f9c66920 80866202 f9c669ac 80855712 badb0d00 nt!CommonDispatchException+0x4d
f9c669ac 80855793 7123642c 00000000 f9c66e00 nt!Kei386EoiHelper+0x18a
f9c66a28 80825700 f9c66e00 f9c66afc 1a60160f nt!RtlDispatchException+0x59
f9c66de4 80866251 f9c66e00 00000000 f9c66e54 nt!KiDispatchException+0x13e
f9c66e4c 80866202 f9c67dac bae1c80c badb0d00 nt!CommonDispatchException+0x4d
f9c66e64 bae587a9 f9c66e7c 8085fcbb f9c60068 nt!Kei386EoiHelper+0x18a
f9c66e74 00000000 f9c66e94 bae1b9d2 00000000
fltMgr!CreateTemporaryFileNameInformation+0xf

MODULE_NAME: nt
IMAGE_NAME: ntkrnlpa.exe
FOLLOWUP_NAME: MachineOwner
DEBUG_FLR_IMAGE_TIMESTAMP: 41107b0c
FOLLOWUP_IP:
nt!KeContextFromKframes+10
80824e3c 53 push ebx
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: nt!KeContextFromKframes+10
STACK_COMMAND: .tss 28 ; kb
FAILURE_BUCKET_ID: TRAP_FRAME_RECURSION
BUCKET_ID: TRAP_FRAME_RECURSION
Followup: MachineOwner
---------

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@vmware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com