FW: UNEXPECTED_KERNEL_MODE_TRAP (7f)

I am using Debug view to see traces…
Its pointing to Debug view driver…
-----Original Message-----
From: Anurag Sarin
Sent: Friday, January 14, 2005 9:06 PM
To: ‘Windows System Software Devs Interest List’
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

It says…

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=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 80464891 to 8042dbbf

STACK_TEXT:
eb435314 80464891 eb435330 00000000 eb435384 nt!KiDispatchException+0x25
eb43537c 80464e7b 00000000 00000000 00000000
nt!CommonDispatchException+0x4d eb43537c 8045a9f8 00000000 00000000
00000000 nt!KiTrap03+0x97 eb4353fc 8045a9c1 00000001 eb43542c 00000000
nt!DebugService+0x10 eb43540c 80454388 eb43542c bb050fd0 bb050e48
nt!DebugPrint+0xd eb435654 eb54c7cc eb435660 4349440a 746f473a
nt!DbgPrint+0xac
WARNING: Stack unwind information not available. Following frames may be
wrong. eb435860 f0e7942d f0e78a20 bb050fd0 bb050e48 Dbgv+0x7cc eb4359c4
80526626 8135e500 bb050e48 00000000 filespy+0x242d eb435a0c bfeee818
00001000 00001000 bfef10fe nt!IovSpecialIrpCompleteRequest+0x18c
eb435a18 bfef10fe 81546908 bb050e48 00000000
Ntfs!NtfsCompleteRequest+0x5c eb435c24 bfef1083 81546908 bb050e48
00000001 Ntfs!NtfsCommonRead+0x161a eb435cc0 805269c4 81810020 bb050e48
81575b50 Ntfs!NtfsFsdRead+0x201 eb435d0c f139411b 815d4820 80064bec
805269c4 nt!IovSpecialIrpCallDriver+0xcd eb435d64 805261cf bb050fd0
bb050ff4 81488e10 SYMEVENT!SYMEvent_GetVMDataPtr+0x697b
eb435d80 f0e78828 8135e500 80064bec bb050fb4 nt!IovCallDriver+0x31
eb435d9c f0e7a994 8135e500 bb050e48 8135e500 filespy+0x1828 eb435db8
805269c4 8135e500 bb050e48 8135e500 filespy+0x3994 eb435e04 8041e445
00000000 00000000 80064bd4 nt!IovSpecialIrpCallDriver+0xcd eb435e18
8043fb41 8169e998 81582ec0 81582ea0 nt!IoPageRead+0xb1 eb435e58 80448a86
00000000 c6040000 c0318100 nt!MiDispatchFault+0x23d eb435ea4 80466a2f
00000000 00000000 00000000 nt!MmAccessFault+0x682 eb435ea4 804116b9
00000000 00000000 00000000 nt!KiTrap0E+0xc3 eb435f74 bff0631c 8169e998
eb435fa8 00001000 nt!CcMapData+0xd9 eb435f98 bff0afb8 81502368 e132c6e8
00000000 Ntfs!NtfsMapStream+0x4b eb435fc8 bff0b2e0 81502368 0000000c
00000000 Ntfs!ReadIndexBuffer+0x8b eb435ff4 bff65095 81502368 e33157c8
eb43609c Ntfs!FindFirstIndexEntry+0x1be eb436058 bff5dafa 81502368
e132c6e8 eb4360f4 Ntfs!NtOfsReadRecords+0xb8 eb436110 bff5dc30 81502368
e3362668 00000000 Ntfs!NtOfsLookupSecurityDescriptorInIndex+0x8a
eb43618c bff5ccb9 81502368 e3362668 0000004c
Ntfs!GetSecurityIdFromSecurityDescriptorUnsafe+0x65
eb4361cc bff08c25 81502368 e3338ac8 0000004c
Ntfs!NtfsCacheSharedSecurityByDescriptor+0x74
eb436220 bff04a89 81502368 e2fee708 81502368
Ntfs!NtfsCacheSharedSecurityForCreate+0xaf
eb436400 bff0f8b3 81502368 bb042e48 bb042f90
Ntfs!NtfsCreateNewFile+0x227 eb43673c bff0c5a2 81502368 bb042e48
eb4367b0 Ntfs!NtfsCommonCreate+0x6eb eb4367f0 805269c4 81810020 bb042e48
815e5e48 Ntfs!NtfsFsdCreate+0x1fe eb43683c f1394273 eb43688c eb046800
00000000 nt!IovSpecialIrpCallDriver+0xcd eb4368f4 805261cf bb042fd0
bb042ff4 81488e10 SYMEVENT!SYMEvent_GetVMDataPtr+0x6ad3
eb436910 f0e78828 8135e500 80064bec bb042fb4 nt!IovCallDriver+0x31
eb43692c f0e7b497 8135e500 bb042e48 8135e500 filespy+0x1828 eb4369bc
805269c4 8135e500 bb042e48 eb436d88 filespy+0x4497 eb436a08 804bda04
804812c0 804bcf50 eb436d0c nt!IovSpecialIrpCallDriver+0xcd eb436b98
8044f5b5 81868bb0 00000000 eb436c50 nt!IopParseDevice+0xab4 eb436c10
804d378b 00000000 818a2500 00000040 nt!ObpLookupObjectName+0x4e7
eb436d20 8049dd31 00000000 00000000 72747400 nt!ObOpenObjectByName+0xc5
eb436dfc 8049d8d6 eb437020 0013019f eb437088 nt!IopCreateFile+0x407
eb436e44 804a5264 eb437020 0013019f eb437088 nt!IoCreateFile+0x36
eb436e84 80463d94 eb437020 0013019f eb437088 nt!NtCreateFile+0x2e
eb436e84 8042e953 eb437020 0013019f eb437088 nt!KiSystemService+0xc4
eb436f28 f0e7f032 eb437020 0013019f eb437088 nt!ZwCreateFile+0xb
eb4370b8 805269c4 8135e500 bb038e48 80064b7c filespy+0x8032 eb437104
804aca56 bb038fd8 00000000 bb038e48 nt!IovSpecialIrpCallDriver+0xcd

FOLLOWUP_IP:
Dbgv+7cc
eb54c7cc eb22 jmp Dbgv+0x7f0 (eb54c7f0)

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Dbgv+7cc

MODULE_NAME: Dbgv

IMAGE_NAME: Dbgv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3b47213b

STACK_COMMAND: .tss 28 ; kb

BUCKET_ID: 0x7f_8_Dbgv+7cc

Followup: MachineOwner

-----Original Message-----
From: Mats PETERSSON [mailto:xxxxx@3dlabs.com]
Sent: Friday, January 14, 2005 8:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

What does ‘analyze -v’ say?


Mats

-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or
any action taken by you in reliance on it, is prohibited and may be
unlawful. If you have received this message in error, please delete it
and contact the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 01/14/2005 03:03:49 PM:

I have a BSOD : UNEXPECTED_KERNEL_MODE_TRAP (7f) on my filter driver
in
W2k.
I have Driver verify on and below o/p.
Can not step trace as BSOD is very random and not on every boot
session. Any Ideas???
kd> .tss 28
eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz
na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx
kd> .trap eb435384
ErrCode = 00000000
eax=00000001 ebx=00000000 ecx=eb43542c edx=00000000 esi=00000000
edi=bb050fd0
eip=8045a9f8 esp=eb4353f8 ebp=eb4353fc iopl=0 nv up ei pl nz
ac
po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00200217
nt!DebugService+0x10:
8045a9f8 8945fc mov [ebp-0x4],eax
ss:0010:eb4353f8=eb43543c
kd> !thread
THREAD 818a1620 Cid 8.20 Teb: 00000000 Win32Thread: 00000000
RUNNING IRP List:
bb042e48: (0006,01b4) Flags: 40000884 Mdl: 00000000
bb038e48: (0006,01b4) Flags: 40000a00 Mdl: 00000000
Not impersonating
Owning Process 818a2b60
Wait Start TickCount 1056281 Elapsed Ticks: 0
Context Switch Count 54448
UserTime 0:00:00.0000
KernelTime 0:00:00.0468
Start Address nt!ExpWorkerThread (0x80416820)
Stack Init eb438000 Current eb4357fc Base eb438000 Limit eb435000 Call

0 Priority 12 BasePriority 12 PriorityDecrement 0 DecrementCount 0
kd> kv
ChildEBP RetAddr Args to Child
00000000 8042dbbf 00000000 00000000 00000000 nt!KiTrap08+0x3e (FPO:
TaskGate 28:0) eb435314 80464891 eb435330 00000000 eb435384 nt!
KiDispatchException+0x25 (FPO: [Non-Fpo])
eb43537c 80464e7b 00000000 00000000 00000000 nt!
CommonDispatchException+0x4d (FPO: [0,20,0])
eb43537c 8045a9f8 00000000 00000000 00000000 nt!KiTrap03+0x97 (FPO:
[0,0] TrapFrame @ eb435384) eb4353fc 8045a9c1 00000001 eb43542c
00000000 nt!DebugService+0x10
(FPO: [Non-Fpo])
eb43540c 80454388 eb43542c bb050fd0 bb050e48 nt!DebugPrint+0xd (FPO:
[1,0,0])
eb435654 eb54c7cc eb435660 4349440a 746f473a nt!DbgPrint+0xac (FPO:
[Non-Fpo])
WARNING: Stack unwind information not available. Following frames may
be wrong. eb435860 f0e7942d f0e78a20 bb050fd0 bb050e48 Dbgv+0x7cc
eb4359c4 80526626 8135e500 bb050e48 00000000 filespy+0x242d
eb435a0c bfeee818 00001000 00001000 bfef10fe nt!
IovSpecialIrpCompleteRequest+0x18c (FPO: [Non-Fpo])
eb435a18 bfef10fe 81546908 bb050e48 00000000 Ntfs!
NtfsCompleteRequest+0x5c (FPO: [3,0,2])
eb435c24 bfef1083 81546908 bb050e48 00000001 Ntfs!
NtfsCommonRead+0x161a (FPO: [Non-Fpo])
eb435cc0 805269c4 81810020 bb050e48 81575b50 Ntfs!NtfsFsdRead+0x201
(FPO: [Non-Fpo])
eb435d0c f139411b 815d4820 80064bec 805269c4 nt!
IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
eb435d64 805261cf bb050fd0 bb050ff4 81488e10 SYMEVENT!
SYMEvent_GetVMDataPtr+0x697b eb435d80 f0e78828 8135e500 80064bec
bb050fb4 nt!IovCallDriver+0x31
(FPO: [Non-Fpo])
eb435d9c f0e7a994 8135e500 bb050e48 8135e500 filespy+0x1828 eb435db8
805269c4 8135e500 bb050e48 8135e500 filespy+0x3994 eb435e04 8041e445
00000000 00000000 80064bd4 nt!
IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
eb435e18 8043fb41 8169e998 81582ec0 81582ea0 nt!IoPageRead+0xb1
(FPO: [Non-Fpo])

Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT0000AE32


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

MessageI am not sure about this but you can use IoGetRemainingStackSize to check the stack space. There is an article on OSR, “Stacking the Deck” with very useful info on the topic.

Regards,

Daniel Terhell
Resplendence Software Projects Sp
xxxxx@resplendence.com
http://www.resplendence.com

“Anurag Sarin” wrote in message news:xxxxx@ntdev…
how Kernel stack overflow possible ?
the Base eb438000 & Limit eb435000
i.e stack range from eb435000 to eb438000.

No stack value is below eb435000 to show a stack over flow…

regards
Anurag
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, January 14, 2005 8:50 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Kernel stack overflow possible.

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

----- Original Message -----
From: Anurag Sarin
To: Windows System Software Devs Interest List
Sent: Friday, January 14, 2005 6:03 PM
Subject: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

I have a BSOD : UNEXPECTED_KERNEL_MODE_TRAP (7f) on my filter driver in W2k.
I have Driver verify on and below o/p.
Can not step trace as BSOD is very random and not on every boot session.

Any Ideas???

kd> .tss 28
eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx

kd> .trap eb435384
ErrCode = 00000000
eax=00000001 ebx=00000000 ecx=eb43542c edx=00000000 esi=00000000 edi=bb050fd0
eip=8045a9f8 esp=eb4353f8 ebp=eb4353fc iopl=0 nv up ei pl nz ac po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00200217
nt!DebugService+0x10:
8045a9f8 8945fc mov [ebp-0x4],eax ss:0010:eb4353f8=eb43543c

kd> !thread
THREAD 818a1620 Cid 8.20 Teb: 00000000 Win32Thread: 00000000 RUNNING
IRP List:
bb042e48: (0006,01b4) Flags: 40000884 Mdl: 00000000
bb038e48: (0006,01b4) Flags: 40000a00 Mdl: 00000000
Not impersonating
Owning Process 818a2b60
Wait Start TickCount 1056281 Elapsed Ticks: 0
Context Switch Count 54448
UserTime 0:00:00.0000
KernelTime 0:00:00.0468
Start Address nt!ExpWorkerThread (0x80416820)
Stack Init eb438000 Current eb4357fc Base eb438000 Limit eb435000 Call 0
Priority 12 BasePriority 12 PriorityDecrement 0 DecrementCount 0

kd> kv
ChildEBP RetAddr Args to Child
00000000 8042dbbf 00000000 00000000 00000000 nt!KiTrap08+0x3e (FPO: TaskGate 28:0)
eb435314 80464891 eb435330 00000000 eb435384 nt!KiDispatchException+0x25 (FPO: [Non-Fpo])
eb43537c 80464e7b 00000000 00000000 00000000 nt!CommonDispatchException+0x4d (FPO: [0,20,0])
eb43537c 8045a9f8 00000000 00000000 00000000 nt!KiTrap03+0x97 (FPO: [0,0] TrapFrame @ eb435384)
eb4353fc 8045a9c1 00000001 eb43542c 00000000 nt!DebugService+0x10 (FPO: [Non-Fpo])
eb43540c 80454388 eb43542c bb050fd0 bb050e48 nt!DebugPrint+0xd (FPO: [1,0,0])
eb435654 eb54c7cc eb435660 4349440a 746f473a nt!DbgPrint+0xac (FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be wrong.
eb435860 f0e7942d f0e78a20 bb050fd0 bb050e48 Dbgv+0x7cc
eb4359c4 80526626 8135e500 bb050e48 00000000 filespy+0x242d
eb435a0c bfeee818 00001000 00001000 bfef10fe nt!IovSpecialIrpCompleteRequest+0x18c (FPO: [Non-Fpo])
eb435a18 bfef10fe 81546908 bb050e48 00000000 Ntfs!NtfsCompleteRequest+0x5c (FPO: [3,0,2])
eb435c24 bfef1083 81546908 bb050e48 00000001 Ntfs!NtfsCommonRead+0x161a (FPO: [Non-Fpo])
eb435cc0 805269c4 81810020 bb050e48 81575b50 Ntfs!NtfsFsdRead+0x201 (FPO: [Non-Fpo])
eb435d0c f139411b 815d4820 80064bec 805269c4 nt!IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
eb435d64 805261cf bb050fd0 bb050ff4 81488e10 SYMEVENT!SYMEvent_GetVMDataPtr+0x697b
eb435d80 f0e78828 8135e500 80064bec bb050fb4 nt!IovCallDriver+0x31 (FPO: [Non-Fpo])
eb435d9c f0e7a994 8135e500 bb050e48 8135e500 filespy+0x1828
eb435db8 805269c4 8135e500 bb050e48 8135e500 filespy+0x3994
eb435e04 8041e445 00000000 00000000 80064bd4 nt!IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
eb435e18 8043fb41 8169e998 81582ec0 81582ea0 nt!IoPageRead+0xb1 (FPO: [Non-Fpo])


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Message
Look at the TSS info:

kd> .tss 28
eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx

ESP is eb434f78, which is already below the stack limit, and you are trying
to push something onto the stack.With a debug message viewing utiltiy, NAV,
filespy, and Verifier running you are going to have to be VERY conservative
with stack space.

-scott


Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Anurag Sarin” wrote in message
news:xxxxx@ntdev…
how Kernel stack overflow possible ?
the Base eb438000 & Limit eb435000
i.e stack range from eb435000 to eb438000.

No stack value is below eb435000 to show a stack over flow…

regards
Anurag
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, January 14, 2005 8:50 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Kernel stack overflow possible.

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

----- Original Message -----
From: Anurag Sarin
To: Windows System Software Devs Interest List
Sent: Friday, January 14, 2005 6:03 PM
Subject: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

I have a BSOD : UNEXPECTED_KERNEL_MODE_TRAP (7f) on my filter driver in W2k.
I have Driver verify on and below o/p.
Can not step trace as BSOD is very random and not on every boot session.
Any Ideas???
kd> .tss 28
eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx
kd> .trap eb435384
ErrCode = 00000000
eax=00000001 ebx=00000000 ecx=eb43542c edx=00000000 esi=00000000
edi=bb050fd0
eip=8045a9f8 esp=eb4353f8 ebp=eb4353fc iopl=0 nv up ei pl nz ac po
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00200217
nt!DebugService+0x10:
8045a9f8 8945fc mov [ebp-0x4],eax
ss:0010:eb4353f8=eb43543c
kd> !thread
THREAD 818a1620 Cid 8.20 Teb: 00000000 Win32Thread: 00000000 RUNNING
IRP List:
bb042e48: (0006,01b4) Flags: 40000884 Mdl: 00000000
bb038e48: (0006,01b4) Flags: 40000a00 Mdl: 00000000
Not impersonating
Owning Process 818a2b60
Wait Start TickCount 1056281 Elapsed Ticks: 0
Context Switch Count 54448
UserTime 0:00:00.0000
KernelTime 0:00:00.0468
Start Address nt!ExpWorkerThread (0x80416820)
Stack Init eb438000 Current eb4357fc Base eb438000 Limit eb435000 Call 0
Priority 12 BasePriority 12 PriorityDecrement 0 DecrementCount 0
kd> kv
ChildEBP RetAddr Args to Child
00000000 8042dbbf 00000000 00000000 00000000 nt!KiTrap08+0x3e (FPO: TaskGate
28:0)
eb435314 80464891 eb435330 00000000 eb435384 nt!KiDispatchException+0x25
(FPO: [Non-Fpo])
eb43537c 80464e7b 00000000 00000000 00000000 nt!CommonDispatchException+0x4d
(FPO: [0,20,0])
eb43537c 8045a9f8 00000000 00000000 00000000 nt!KiTrap03+0x97 (FPO: [0,0]
TrapFrame @ eb435384)
eb4353fc 8045a9c1 00000001 eb43542c 00000000 nt!DebugService+0x10 (FPO:
[Non-Fpo])
eb43540c 80454388 eb43542c bb050fd0 bb050e48 nt!DebugPrint+0xd (FPO:
[1,0,0])
eb435654 eb54c7cc eb435660 4349440a 746f473a nt!DbgPrint+0xac (FPO:
[Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be
wrong.
eb435860 f0e7942d f0e78a20 bb050fd0 bb050e48 Dbgv+0x7cc
eb4359c4 80526626 8135e500 bb050e48 00000000 filespy+0x242d
eb435a0c bfeee818 00001000 00001000 bfef10fe
nt!IovSpecialIrpCompleteRequest+0x18c (FPO: [Non-Fpo])
eb435a18 bfef10fe 81546908 bb050e48 00000000 Ntfs!NtfsCompleteRequest+0x5c
(FPO: [3,0,2])
eb435c24 bfef1083 81546908 bb050e48 00000001 Ntfs!NtfsCommonRead+0x161a
(FPO: [Non-Fpo])
eb435cc0 805269c4 81810020 bb050e48 81575b50 Ntfs!NtfsFsdRead+0x201 (FPO:
[Non-Fpo])
eb435d0c f139411b 815d4820 80064bec 805269c4 nt!IovSpecialIrpCallDriver+0xcd
(FPO: [Non-Fpo])
eb435d64 805261cf bb050fd0 bb050ff4 81488e10
SYMEVENT!SYMEvent_GetVMDataPtr+0x697b
eb435d80 f0e78828 8135e500 80064bec bb050fb4 nt!IovCallDriver+0x31 (FPO:
[Non-Fpo])
eb435d9c f0e7a994 8135e500 bb050e48 8135e500 filespy+0x1828
eb435db8 805269c4 8135e500 bb050e48 8135e500 filespy+0x3994
eb435e04 8041e445 00000000 00000000 80064bd4 nt!IovSpecialIrpCallDriver+0xcd
(FPO: [Non-Fpo])
eb435e18 8043fb41 8169e998 81582ec0 81582ea0 nt!IoPageRead+0xb1 (FPO:
[Non-Fpo])

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

When DebugPrint is on the stack in a crash it is almost always bad printf
input specification.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: Friday, January 14, 2005 10:13 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

What does ‘analyze -v’ say?


Mats

-------- Notice --------
The information in this message is confidential and may be
legally privileged. It is intended solely for the addressee.
Access to this message by anyone else is unauthorized. If
you are not the intended recipient, any disclosure, copying
or distribution of the message, or any action taken by you in
reliance on it, is prohibited and may be unlawful.
If you have received this message in error, please delete it
and contact the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 01/14/2005 03:03:49 PM:

> I have a BSOD : UNEXPECTED_KERNEL_MODE_TRAP (7f) on my
filter driver
> in
W2k.
> I have Driver verify on and below o/p.
> Can not step trace as BSOD is very random and not on every
boot session.
> Any Ideas???
> kd> .tss 28
> eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
> eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up
di ng nz na
po nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
> nt!KiDispatchException+0x25:
> 8042dbbf 53 push ebx
> kd> .trap eb435384
> ErrCode = 00000000
> eax=00000001 ebx=00000000 ecx=eb43542c edx=00000000 esi=00000000
edi=bb050fd0
> eip=8045a9f8 esp=eb4353f8 ebp=eb4353fc iopl=0 nv up
ei pl nz ac
po cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00200217
> nt!DebugService+0x10:
> 8045a9f8 8945fc mov [ebp-0x4],eax
ss:0010:eb4353f8=eb43543c
> kd> !thread
> THREAD 818a1620 Cid 8.20 Teb: 00000000 Win32Thread: 00000000
> RUNNING IRP List:
> bb042e48: (0006,01b4) Flags: 40000884 Mdl: 00000000
> bb038e48: (0006,01b4) Flags: 40000a00 Mdl: 00000000 Not
> impersonating Owning Process 818a2b60
> Wait Start TickCount 1056281 Elapsed Ticks: 0
> Context Switch Count 54448
> UserTime 0:00:00.0000
> KernelTime 0:00:00.0468
> Start Address nt!ExpWorkerThread (0x80416820) Stack Init eb438000
> Current eb4357fc Base eb438000 Limit eb435000 Call 0 Priority 12
> BasePriority 12 PriorityDecrement 0 DecrementCount 0
> kd> kv
> ChildEBP RetAddr Args to Child
> 00000000 8042dbbf 00000000 00000000 00000000 nt!KiTrap08+0x3e (FPO:
> TaskGate 28:0)
> eb435314 80464891 eb435330 00000000 eb435384 nt!
> KiDispatchException+0x25 (FPO: [Non-Fpo])
> eb43537c 80464e7b 00000000 00000000 00000000 nt!
> CommonDispatchException+0x4d (FPO: [0,20,0])
> eb43537c 8045a9f8 00000000 00000000 00000000 nt!KiTrap03+0x97 (FPO:
> [0,0] TrapFrame @ eb435384)
> eb4353fc 8045a9c1 00000001 eb43542c 00000000 nt!DebugService+0x10
> (FPO: [Non-Fpo])
> eb43540c 80454388 eb43542c bb050fd0 bb050e48 nt!DebugPrint+0xd (FPO:
[1,0,0])
> eb435654 eb54c7cc eb435660 4349440a 746f473a nt!DbgPrint+0xac (FPO:
[Non-Fpo])
> WARNING: Stack unwind information not available. Following
frames may
> be wrong.
> eb435860 f0e7942d f0e78a20 bb050fd0 bb050e48 Dbgv+0x7cc
> eb4359c4 80526626 8135e500 bb050e48 00000000 filespy+0x242d
eb435a0c
> bfeee818 00001000 00001000 bfef10fe nt!
> IovSpecialIrpCompleteRequest+0x18c (FPO: [Non-Fpo])
> eb435a18 bfef10fe 81546908 bb050e48 00000000 Ntfs!
> NtfsCompleteRequest+0x5c (FPO: [3,0,2])
> eb435c24 bfef1083 81546908 bb050e48 00000001 Ntfs!
> NtfsCommonRead+0x161a (FPO: [Non-Fpo])
> eb435cc0 805269c4 81810020 bb050e48 81575b50 Ntfs!NtfsFsdRead+0x201
> (FPO: [Non-Fpo])
> eb435d0c f139411b 815d4820 80064bec 805269c4 nt!
> IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
> eb435d64 805261cf bb050fd0 bb050ff4 81488e10 SYMEVENT!
> SYMEvent_GetVMDataPtr+0x697b
> eb435d80 f0e78828 8135e500 80064bec bb050fb4 nt!IovCallDriver+0x31
> (FPO: [Non-Fpo])
> eb435d9c f0e7a994 8135e500 bb050e48 8135e500 filespy+0x1828
> eb435db8 805269c4 8135e500 bb050e48 8135e500 filespy+0x3994
> eb435e04 8041e445 00000000 00000000 80064bd4 nt!
> IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
> eb435e18 8043fb41 8169e998 81582ec0 81582ea0 nt!IoPageRead+0xb1
> (FPO: [Non-Fpo])
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst
tag argument:
‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> ForwardSourceID:NT0000AE32


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

It does appear to be a stack fault owing to recursion. I see filespy in the
call stack twice; the second one is probably due to Symantec driver
recursing into the file system via its service to perform the actual scan.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Friday, January 14, 2005 10:36 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

It says…

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=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 80464891 to 8042dbbf

STACK_TEXT:
eb435314 80464891 eb435330 00000000 eb435384 nt!KiDispatchException+0x25
eb43537c 80464e7b 00000000 00000000 00000000
nt!CommonDispatchException+0x4d
eb43537c 8045a9f8 00000000 00000000 00000000 nt!KiTrap03+0x97
eb4353fc 8045a9c1 00000001 eb43542c 00000000 nt!DebugService+0x10
eb43540c 80454388 eb43542c bb050fd0 bb050e48 nt!DebugPrint+0xd
eb435654 eb54c7cc eb435660 4349440a 746f473a nt!DbgPrint+0xac
WARNING: Stack unwind information not available. Following frames may be
wrong.
eb435860 f0e7942d f0e78a20 bb050fd0 bb050e48 Dbgv+0x7cc
eb4359c4 80526626 8135e500 bb050e48 00000000 filespy+0x242d
eb435a0c bfeee818 00001000 00001000 bfef10fe
nt!IovSpecialIrpCompleteRequest+0x18c
eb435a18 bfef10fe 81546908 bb050e48 00000000
Ntfs!NtfsCompleteRequest+0x5c
eb435c24 bfef1083 81546908 bb050e48 00000001 Ntfs!NtfsCommonRead+0x161a
eb435cc0 805269c4 81810020 bb050e48 81575b50 Ntfs!NtfsFsdRead+0x201
eb435d0c f139411b 815d4820 80064bec 805269c4
nt!IovSpecialIrpCallDriver+0xcd
eb435d64 805261cf bb050fd0 bb050ff4 81488e10
SYMEVENT!SYMEvent_GetVMDataPtr+0x697b
eb435d80 f0e78828 8135e500 80064bec bb050fb4 nt!IovCallDriver+0x31
eb435d9c f0e7a994 8135e500 bb050e48 8135e500 filespy+0x1828
eb435db8 805269c4 8135e500 bb050e48 8135e500 filespy+0x3994
eb435e04 8041e445 00000000 00000000 80064bd4
nt!IovSpecialIrpCallDriver+0xcd
eb435e18 8043fb41 8169e998 81582ec0 81582ea0 nt!IoPageRead+0xb1
eb435e58 80448a86 00000000 c6040000 c0318100 nt!MiDispatchFault+0x23d
eb435ea4 80466a2f 00000000 00000000 00000000 nt!MmAccessFault+0x682
eb435ea4 804116b9 00000000 00000000 00000000 nt!KiTrap0E+0xc3
eb435f74 bff0631c 8169e998 eb435fa8 00001000 nt!CcMapData+0xd9
eb435f98 bff0afb8 81502368 e132c6e8 00000000 Ntfs!NtfsMapStream+0x4b
eb435fc8 bff0b2e0 81502368 0000000c 00000000 Ntfs!ReadIndexBuffer+0x8b
eb435ff4 bff65095 81502368 e33157c8 eb43609c
Ntfs!FindFirstIndexEntry+0x1be
eb436058 bff5dafa 81502368 e132c6e8 eb4360f4 Ntfs!NtOfsReadRecords+0xb8
eb436110 bff5dc30 81502368 e3362668 00000000
Ntfs!NtOfsLookupSecurityDescriptorInIndex+0x8a
eb43618c bff5ccb9 81502368 e3362668 0000004c
Ntfs!GetSecurityIdFromSecurityDescriptorUnsafe+0x65
eb4361cc bff08c25 81502368 e3338ac8 0000004c
Ntfs!NtfsCacheSharedSecurityByDescriptor+0x74
eb436220 bff04a89 81502368 e2fee708 81502368
Ntfs!NtfsCacheSharedSecurityForCreate+0xaf
eb436400 bff0f8b3 81502368 bb042e48 bb042f90
Ntfs!NtfsCreateNewFile+0x227
eb43673c bff0c5a2 81502368 bb042e48 eb4367b0 Ntfs!NtfsCommonCreate+0x6eb
eb4367f0 805269c4 81810020 bb042e48 815e5e48 Ntfs!NtfsFsdCreate+0x1fe
eb43683c f1394273 eb43688c eb046800 00000000
nt!IovSpecialIrpCallDriver+0xcd
eb4368f4 805261cf bb042fd0 bb042ff4 81488e10
SYMEVENT!SYMEvent_GetVMDataPtr+0x6ad3
eb436910 f0e78828 8135e500 80064bec bb042fb4 nt!IovCallDriver+0x31
eb43692c f0e7b497 8135e500 bb042e48 8135e500 filespy+0x1828
eb4369bc 805269c4 8135e500 bb042e48 eb436d88 filespy+0x4497
eb436a08 804bda04 804812c0 804bcf50 eb436d0c
nt!IovSpecialIrpCallDriver+0xcd
eb436b98 8044f5b5 81868bb0 00000000 eb436c50 nt!IopParseDevice+0xab4
eb436c10 804d378b 00000000 818a2500 00000040
nt!ObpLookupObjectName+0x4e7
eb436d20 8049dd31 00000000 00000000 72747400 nt!ObOpenObjectByName+0xc5
eb436dfc 8049d8d6 eb437020 0013019f eb437088 nt!IopCreateFile+0x407
eb436e44 804a5264 eb437020 0013019f eb437088 nt!IoCreateFile+0x36
eb436e84 80463d94 eb437020 0013019f eb437088 nt!NtCreateFile+0x2e
eb436e84 8042e953 eb437020 0013019f eb437088 nt!KiSystemService+0xc4
eb436f28 f0e7f032 eb437020 0013019f eb437088 nt!ZwCreateFile+0xb
eb4370b8 805269c4 8135e500 bb038e48 80064b7c filespy+0x8032
eb437104 804aca56 bb038fd8 00000000 bb038e48
nt!IovSpecialIrpCallDriver+0xcd

FOLLOWUP_IP:
Dbgv+7cc
eb54c7cc eb22 jmp Dbgv+0x7f0 (eb54c7f0)

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Dbgv+7cc

MODULE_NAME: Dbgv

IMAGE_NAME: Dbgv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3b47213b

STACK_COMMAND: .tss 28 ; kb

BUCKET_ID: 0x7f_8_Dbgv+7cc

Followup: MachineOwner

-----Original Message-----
From: Mats PETERSSON [mailto:xxxxx@3dlabs.com]
Sent: Friday, January 14, 2005 8:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

What does ‘analyze -v’ say?


Mats

-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or
any action taken by you in reliance on it, is prohibited and may be
unlawful. If you have received this message in error, please delete it
and contact the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 01/14/2005 03:03:49 PM:

I have a BSOD : UNEXPECTED_KERNEL_MODE_TRAP (7f) on my filter driver
in
W2k.
I have Driver verify on and below o/p.
Can not step trace as BSOD is very random and not on every boot
session. Any Ideas???
kd> .tss 28
eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz
na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx
kd> .trap eb435384
ErrCode = 00000000
eax=00000001 ebx=00000000 ecx=eb43542c edx=00000000 esi=00000000
edi=bb050fd0
eip=8045a9f8 esp=eb4353f8 ebp=eb4353fc iopl=0 nv up ei pl nz
ac
po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00200217
nt!DebugService+0x10:
8045a9f8 8945fc mov [ebp-0x4],eax
ss:0010:eb4353f8=eb43543c
kd> !thread
THREAD 818a1620 Cid 8.20 Teb: 00000000 Win32Thread: 00000000
RUNNING IRP List:
bb042e48: (0006,01b4) Flags: 40000884 Mdl: 00000000
bb038e48: (0006,01b4) Flags: 40000a00 Mdl: 00000000
Not impersonating
Owning Process 818a2b60
Wait Start TickCount 1056281 Elapsed Ticks: 0
Context Switch Count 54448
UserTime 0:00:00.0000
KernelTime 0:00:00.0468
Start Address nt!ExpWorkerThread (0x80416820)
Stack Init eb438000 Current eb4357fc Base eb438000 Limit eb435000 Call

0 Priority 12 BasePriority 12 PriorityDecrement 0 DecrementCount 0
kd> kv
ChildEBP RetAddr Args to Child
00000000 8042dbbf 00000000 00000000 00000000 nt!KiTrap08+0x3e (FPO:
TaskGate 28:0) eb435314 80464891 eb435330 00000000 eb435384 nt!
KiDispatchException+0x25 (FPO: [Non-Fpo])
eb43537c 80464e7b 00000000 00000000 00000000 nt!
CommonDispatchException+0x4d (FPO: [0,20,0])
eb43537c 8045a9f8 00000000 00000000 00000000 nt!KiTrap03+0x97 (FPO:
[0,0] TrapFrame @ eb435384) eb4353fc 8045a9c1 00000001 eb43542c
00000000 nt!DebugService+0x10
(FPO: [Non-Fpo])
eb43540c 80454388 eb43542c bb050fd0 bb050e48 nt!DebugPrint+0xd (FPO:
[1,0,0])
eb435654 eb54c7cc eb435660 4349440a 746f473a nt!DbgPrint+0xac (FPO:
[Non-Fpo])
WARNING: Stack unwind information not available. Following frames may
be wrong. eb435860 f0e7942d f0e78a20 bb050fd0 bb050e48 Dbgv+0x7cc
eb4359c4 80526626 8135e500 bb050e48 00000000 filespy+0x242d
eb435a0c bfeee818 00001000 00001000 bfef10fe nt!
IovSpecialIrpCompleteRequest+0x18c (FPO: [Non-Fpo])
eb435a18 bfef10fe 81546908 bb050e48 00000000 Ntfs!
NtfsCompleteRequest+0x5c (FPO: [3,0,2])
eb435c24 bfef1083 81546908 bb050e48 00000001 Ntfs!
NtfsCommonRead+0x161a (FPO: [Non-Fpo])
eb435cc0 805269c4 81810020 bb050e48 81575b50 Ntfs!NtfsFsdRead+0x201
(FPO: [Non-Fpo])
eb435d0c f139411b 815d4820 80064bec 805269c4 nt!
IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
eb435d64 805261cf bb050fd0 bb050ff4 81488e10 SYMEVENT!
SYMEvent_GetVMDataPtr+0x697b eb435d80 f0e78828 8135e500 80064bec
bb050fb4 nt!IovCallDriver+0x31
(FPO: [Non-Fpo])
eb435d9c f0e7a994 8135e500 bb050e48 8135e500 filespy+0x1828 eb435db8
805269c4 8135e500 bb050e48 8135e500 filespy+0x3994 eb435e04 8041e445
00000000 00000000 80064bd4 nt!
IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
eb435e18 8043fb41 8169e998 81582ec0 81582ea0 nt!IoPageRead+0xb1
(FPO: [Non-Fpo])

Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT0000AE32


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

__________ NOD32 1.970 (20050113) Information __________

This message was checked by NOD32 antivirus system.
http://www.nod32.com

Another note: When ever you see a call stack this large, you can be
relatively sure that the issue is a stack overflow.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Friday, January 14, 2005 10:36 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

It says…

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=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 80464891 to 8042dbbf

STACK_TEXT:
eb435314 80464891 eb435330 00000000 eb435384 nt!KiDispatchException+0x25
eb43537c 80464e7b 00000000 00000000 00000000
nt!CommonDispatchException+0x4d
eb43537c 8045a9f8 00000000 00000000 00000000 nt!KiTrap03+0x97
eb4353fc 8045a9c1 00000001 eb43542c 00000000 nt!DebugService+0x10
eb43540c 80454388 eb43542c bb050fd0 bb050e48 nt!DebugPrint+0xd
eb435654 eb54c7cc eb435660 4349440a 746f473a nt!DbgPrint+0xac
WARNING: Stack unwind information not available. Following frames may be
wrong.
eb435860 f0e7942d f0e78a20 bb050fd0 bb050e48 Dbgv+0x7cc
eb4359c4 80526626 8135e500 bb050e48 00000000 filespy+0x242d
eb435a0c bfeee818 00001000 00001000 bfef10fe
nt!IovSpecialIrpCompleteRequest+0x18c
eb435a18 bfef10fe 81546908 bb050e48 00000000
Ntfs!NtfsCompleteRequest+0x5c
eb435c24 bfef1083 81546908 bb050e48 00000001 Ntfs!NtfsCommonRead+0x161a
eb435cc0 805269c4 81810020 bb050e48 81575b50 Ntfs!NtfsFsdRead+0x201
eb435d0c f139411b 815d4820 80064bec 805269c4
nt!IovSpecialIrpCallDriver+0xcd
eb435d64 805261cf bb050fd0 bb050ff4 81488e10
SYMEVENT!SYMEvent_GetVMDataPtr+0x697b
eb435d80 f0e78828 8135e500 80064bec bb050fb4 nt!IovCallDriver+0x31
eb435d9c f0e7a994 8135e500 bb050e48 8135e500 filespy+0x1828
eb435db8 805269c4 8135e500 bb050e48 8135e500 filespy+0x3994
eb435e04 8041e445 00000000 00000000 80064bd4
nt!IovSpecialIrpCallDriver+0xcd
eb435e18 8043fb41 8169e998 81582ec0 81582ea0 nt!IoPageRead+0xb1
eb435e58 80448a86 00000000 c6040000 c0318100 nt!MiDispatchFault+0x23d
eb435ea4 80466a2f 00000000 00000000 00000000 nt!MmAccessFault+0x682
eb435ea4 804116b9 00000000 00000000 00000000 nt!KiTrap0E+0xc3
eb435f74 bff0631c 8169e998 eb435fa8 00001000 nt!CcMapData+0xd9
eb435f98 bff0afb8 81502368 e132c6e8 00000000 Ntfs!NtfsMapStream+0x4b
eb435fc8 bff0b2e0 81502368 0000000c 00000000 Ntfs!ReadIndexBuffer+0x8b
eb435ff4 bff65095 81502368 e33157c8 eb43609c
Ntfs!FindFirstIndexEntry+0x1be
eb436058 bff5dafa 81502368 e132c6e8 eb4360f4 Ntfs!NtOfsReadRecords+0xb8
eb436110 bff5dc30 81502368 e3362668 00000000
Ntfs!NtOfsLookupSecurityDescriptorInIndex+0x8a
eb43618c bff5ccb9 81502368 e3362668 0000004c
Ntfs!GetSecurityIdFromSecurityDescriptorUnsafe+0x65
eb4361cc bff08c25 81502368 e3338ac8 0000004c
Ntfs!NtfsCacheSharedSecurityByDescriptor+0x74
eb436220 bff04a89 81502368 e2fee708 81502368
Ntfs!NtfsCacheSharedSecurityForCreate+0xaf
eb436400 bff0f8b3 81502368 bb042e48 bb042f90
Ntfs!NtfsCreateNewFile+0x227
eb43673c bff0c5a2 81502368 bb042e48 eb4367b0 Ntfs!NtfsCommonCreate+0x6eb
eb4367f0 805269c4 81810020 bb042e48 815e5e48 Ntfs!NtfsFsdCreate+0x1fe
eb43683c f1394273 eb43688c eb046800 00000000
nt!IovSpecialIrpCallDriver+0xcd
eb4368f4 805261cf bb042fd0 bb042ff4 81488e10
SYMEVENT!SYMEvent_GetVMDataPtr+0x6ad3
eb436910 f0e78828 8135e500 80064bec bb042fb4 nt!IovCallDriver+0x31
eb43692c f0e7b497 8135e500 bb042e48 8135e500 filespy+0x1828
eb4369bc 805269c4 8135e500 bb042e48 eb436d88 filespy+0x4497
eb436a08 804bda04 804812c0 804bcf50 eb436d0c
nt!IovSpecialIrpCallDriver+0xcd
eb436b98 8044f5b5 81868bb0 00000000 eb436c50 nt!IopParseDevice+0xab4
eb436c10 804d378b 00000000 818a2500 00000040
nt!ObpLookupObjectName+0x4e7
eb436d20 8049dd31 00000000 00000000 72747400 nt!ObOpenObjectByName+0xc5
eb436dfc 8049d8d6 eb437020 0013019f eb437088 nt!IopCreateFile+0x407
eb436e44 804a5264 eb437020 0013019f eb437088 nt!IoCreateFile+0x36
eb436e84 80463d94 eb437020 0013019f eb437088 nt!NtCreateFile+0x2e
eb436e84 8042e953 eb437020 0013019f eb437088 nt!KiSystemService+0xc4
eb436f28 f0e7f032 eb437020 0013019f eb437088 nt!ZwCreateFile+0xb
eb4370b8 805269c4 8135e500 bb038e48 80064b7c filespy+0x8032
eb437104 804aca56 bb038fd8 00000000 bb038e48
nt!IovSpecialIrpCallDriver+0xcd

FOLLOWUP_IP:
Dbgv+7cc
eb54c7cc eb22 jmp Dbgv+0x7f0 (eb54c7f0)

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Dbgv+7cc

MODULE_NAME: Dbgv

IMAGE_NAME: Dbgv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3b47213b

STACK_COMMAND: .tss 28 ; kb

BUCKET_ID: 0x7f_8_Dbgv+7cc

Followup: MachineOwner

-----Original Message-----
From: Mats PETERSSON [mailto:xxxxx@3dlabs.com]
Sent: Friday, January 14, 2005 8:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

What does ‘analyze -v’ say?


Mats

-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or
any action taken by you in reliance on it, is prohibited and may be
unlawful. If you have received this message in error, please delete it
and contact the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 01/14/2005 03:03:49 PM:

I have a BSOD : UNEXPECTED_KERNEL_MODE_TRAP (7f) on my filter driver
in
W2k.
I have Driver verify on and below o/p.
Can not step trace as BSOD is very random and not on every boot
session. Any Ideas???
kd> .tss 28
eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz
na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx
kd> .trap eb435384
ErrCode = 00000000
eax=00000001 ebx=00000000 ecx=eb43542c edx=00000000 esi=00000000
edi=bb050fd0
eip=8045a9f8 esp=eb4353f8 ebp=eb4353fc iopl=0 nv up ei pl nz
ac
po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00200217
nt!DebugService+0x10:
8045a9f8 8945fc mov [ebp-0x4],eax
ss:0010:eb4353f8=eb43543c
kd> !thread
THREAD 818a1620 Cid 8.20 Teb: 00000000 Win32Thread: 00000000
RUNNING IRP List:
bb042e48: (0006,01b4) Flags: 40000884 Mdl: 00000000
bb038e48: (0006,01b4) Flags: 40000a00 Mdl: 00000000
Not impersonating
Owning Process 818a2b60
Wait Start TickCount 1056281 Elapsed Ticks: 0
Context Switch Count 54448
UserTime 0:00:00.0000
KernelTime 0:00:00.0468
Start Address nt!ExpWorkerThread (0x80416820)
Stack Init eb438000 Current eb4357fc Base eb438000 Limit eb435000 Call

0 Priority 12 BasePriority 12 PriorityDecrement 0 DecrementCount 0
kd> kv
ChildEBP RetAddr Args to Child
00000000 8042dbbf 00000000 00000000 00000000 nt!KiTrap08+0x3e (FPO:
TaskGate 28:0) eb435314 80464891 eb435330 00000000 eb435384 nt!
KiDispatchException+0x25 (FPO: [Non-Fpo])
eb43537c 80464e7b 00000000 00000000 00000000 nt!
CommonDispatchException+0x4d (FPO: [0,20,0])
eb43537c 8045a9f8 00000000 00000000 00000000 nt!KiTrap03+0x97 (FPO:
[0,0] TrapFrame @ eb435384) eb4353fc 8045a9c1 00000001 eb43542c
00000000 nt!DebugService+0x10
(FPO: [Non-Fpo])
eb43540c 80454388 eb43542c bb050fd0 bb050e48 nt!DebugPrint+0xd (FPO:
[1,0,0])
eb435654 eb54c7cc eb435660 4349440a 746f473a nt!DbgPrint+0xac (FPO:
[Non-Fpo])
WARNING: Stack unwind information not available. Following frames may
be wrong. eb435860 f0e7942d f0e78a20 bb050fd0 bb050e48 Dbgv+0x7cc
eb4359c4 80526626 8135e500 bb050e48 00000000 filespy+0x242d
eb435a0c bfeee818 00001000 00001000 bfef10fe nt!
IovSpecialIrpCompleteRequest+0x18c (FPO: [Non-Fpo])
eb435a18 bfef10fe 81546908 bb050e48 00000000 Ntfs!
NtfsCompleteRequest+0x5c (FPO: [3,0,2])
eb435c24 bfef1083 81546908 bb050e48 00000001 Ntfs!
NtfsCommonRead+0x161a (FPO: [Non-Fpo])
eb435cc0 805269c4 81810020 bb050e48 81575b50 Ntfs!NtfsFsdRead+0x201
(FPO: [Non-Fpo])
eb435d0c f139411b 815d4820 80064bec 805269c4 nt!
IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
eb435d64 805261cf bb050fd0 bb050ff4 81488e10 SYMEVENT!
SYMEvent_GetVMDataPtr+0x697b eb435d80 f0e78828 8135e500 80064bec
bb050fb4 nt!IovCallDriver+0x31
(FPO: [Non-Fpo])
eb435d9c f0e7a994 8135e500 bb050e48 8135e500 filespy+0x1828 eb435db8
805269c4 8135e500 bb050e48 8135e500 filespy+0x3994 eb435e04 8041e445
00000000 00000000 80064bd4 nt!
IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
eb435e18 8043fb41 8169e998 81582ec0 81582ea0 nt!IoPageRead+0xb1
(FPO: [Non-Fpo])

Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT0000AE32


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

__________ NOD32 1.970 (20050113) Information __________

This message was checked by NOD32 antivirus system.
http://www.nod32.com

Just for knowledge :- Could you tell me which part of .tss output tells
us that it’s a double fault case… And why ??

Also which command will give me amount of stack consumed per function?

Thanks & Regards
Anurag

-----Original Message-----
From: Calvin Guan [mailto:xxxxx@ati.com]
Sent: Friday, January 14, 2005 8:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

kd> .tss 28
eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz na
po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx

This is a typical double fault caused by stack overflow.

Check if there’s endless recursion call in the call stack or see which
function consumed abnormal amount of stack. !analyze -v is your first
step to triage.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Try
kd>.tss 28 (switch to the fault)
kd>kf 50 (dump 0x50 frames and the distance of each frame)

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com

-----Original Message-----
From: Anurag Sarin [mailto:xxxxx@divassoftware.com]
Sent: January 14, 2005 10:52 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Just for knowledge :- Could you tell me which part of .tss
output tells us that it’s a double fault case… And why ??

Also which command will give me amount of stack consumed per function?

Thanks & Regards
Anurag

-----Original Message-----
From: Calvin Guan [mailto:xxxxx@ati.com]
Sent: Friday, January 14, 2005 8:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

>kd> .tss 28
>eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
>eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up
di ng nz na
po
nc
>cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
>nt!KiDispatchException+0x25:
>8042dbbf 53 push ebx

This is a typical double fault caused by stack overflow.

Check if there’s endless recursion call in the call stack or
see which function consumed abnormal amount of stack.
!analyze -v is your first step to triage.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Ok, so that confirms that it’s a stack overflow (or at least nearly
certain, especially since the stack pointer isn’t zero). A double fault can
only be caused by another fault being handled that in itself fails.

Either something is recursing (I see filespy+1828 on several levels of the
stack, but that may be correct), or something is using big chunks of stack.


Mats

-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or any
action taken by you in reliance on it, is prohibited and may be unlawful.
If you have received this message in error, please delete it and contact
the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 01/14/2005 03:35:57 PM:

It says…

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=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 80464891 to 8042dbbf

STACK_TEXT:
eb435314 80464891 eb435330 00000000 eb435384 nt!KiDispatchException+0x25
eb43537c 80464e7b 00000000 00000000 00000000
nt!CommonDispatchException+0x4d
eb43537c 8045a9f8 00000000 00000000 00000000 nt!KiTrap03+0x97
eb4353fc 8045a9c1 00000001 eb43542c 00000000 nt!DebugService+0x10
eb43540c 80454388 eb43542c bb050fd0 bb050e48 nt!DebugPrint+0xd
eb435654 eb54c7cc eb435660 4349440a 746f473a nt!DbgPrint+0xac
WARNING: Stack unwind information not available. Following frames may be
wrong.
eb435860 f0e7942d f0e78a20 bb050fd0 bb050e48 Dbgv+0x7cc
eb4359c4 80526626 8135e500 bb050e48 00000000 filespy+0x242d
eb435a0c bfeee818 00001000 00001000 bfef10fe
nt!IovSpecialIrpCompleteRequest+0x18c
eb435a18 bfef10fe 81546908 bb050e48 00000000
Ntfs!NtfsCompleteRequest+0x5c
eb435c24 bfef1083 81546908 bb050e48 00000001 Ntfs!NtfsCommonRead+0x161a
eb435cc0 805269c4 81810020 bb050e48 81575b50 Ntfs!NtfsFsdRead+0x201
eb435d0c f139411b 815d4820 80064bec 805269c4
nt!IovSpecialIrpCallDriver+0xcd
eb435d64 805261cf bb050fd0 bb050ff4 81488e10
SYMEVENT!SYMEvent_GetVMDataPtr+0x697b
eb435d80 f0e78828 8135e500 80064bec bb050fb4 nt!IovCallDriver+0x31
eb435d9c f0e7a994 8135e500 bb050e48 8135e500 filespy+0x1828
eb435db8 805269c4 8135e500 bb050e48 8135e500 filespy+0x3994
eb435e04 8041e445 00000000 00000000 80064bd4
nt!IovSpecialIrpCallDriver+0xcd
eb435e18 8043fb41 8169e998 81582ec0 81582ea0 nt!IoPageRead+0xb1
eb435e58 80448a86 00000000 c6040000 c0318100 nt!MiDispatchFault+0x23d
eb435ea4 80466a2f 00000000 00000000 00000000 nt!MmAccessFault+0x682
eb435ea4 804116b9 00000000 00000000 00000000 nt!KiTrap0E+0xc3
eb435f74 bff0631c 8169e998 eb435fa8 00001000 nt!CcMapData+0xd9
eb435f98 bff0afb8 81502368 e132c6e8 00000000 Ntfs!NtfsMapStream+0x4b
eb435fc8 bff0b2e0 81502368 0000000c 00000000 Ntfs!ReadIndexBuffer+0x8b
eb435ff4 bff65095 81502368 e33157c8 eb43609c
Ntfs!FindFirstIndexEntry+0x1be
eb436058 bff5dafa 81502368 e132c6e8 eb4360f4 Ntfs!NtOfsReadRecords+0xb8
eb436110 bff5dc30 81502368 e3362668 00000000
Ntfs!NtOfsLookupSecurityDescriptorInIndex+0x8a
eb43618c bff5ccb9 81502368 e3362668 0000004c
Ntfs!GetSecurityIdFromSecurityDescriptorUnsafe+0x65
eb4361cc bff08c25 81502368 e3338ac8 0000004c
Ntfs!NtfsCacheSharedSecurityByDescriptor+0x74
eb436220 bff04a89 81502368 e2fee708 81502368
Ntfs!NtfsCacheSharedSecurityForCreate+0xaf
eb436400 bff0f8b3 81502368 bb042e48 bb042f90
Ntfs!NtfsCreateNewFile+0x227
eb43673c bff0c5a2 81502368 bb042e48 eb4367b0 Ntfs!NtfsCommonCreate+0x6eb
eb4367f0 805269c4 81810020 bb042e48 815e5e48 Ntfs!NtfsFsdCreate+0x1fe
eb43683c f1394273 eb43688c eb046800 00000000
nt!IovSpecialIrpCallDriver+0xcd
eb4368f4 805261cf bb042fd0 bb042ff4 81488e10
SYMEVENT!SYMEvent_GetVMDataPtr+0x6ad3
eb436910 f0e78828 8135e500 80064bec bb042fb4 nt!IovCallDriver+0x31
eb43692c f0e7b497 8135e500 bb042e48 8135e500 filespy+0x1828
eb4369bc 805269c4 8135e500 bb042e48 eb436d88 filespy+0x4497
eb436a08 804bda04 804812c0 804bcf50 eb436d0c
nt!IovSpecialIrpCallDriver+0xcd
eb436b98 8044f5b5 81868bb0 00000000 eb436c50 nt!IopParseDevice+0xab4
eb436c10 804d378b 00000000 818a2500 00000040
nt!ObpLookupObjectName+0x4e7
eb436d20 8049dd31 00000000 00000000 72747400 nt!ObOpenObjectByName+0xc5
eb436dfc 8049d8d6 eb437020 0013019f eb437088 nt!IopCreateFile+0x407
eb436e44 804a5264 eb437020 0013019f eb437088 nt!IoCreateFile+0x36
eb436e84 80463d94 eb437020 0013019f eb437088 nt!NtCreateFile+0x2e
eb436e84 8042e953 eb437020 0013019f eb437088 nt!KiSystemService+0xc4
eb436f28 f0e7f032 eb437020 0013019f eb437088 nt!ZwCreateFile+0xb
eb4370b8 805269c4 8135e500 bb038e48 80064b7c filespy+0x8032
eb437104 804aca56 bb038fd8 00000000 bb038e48
nt!IovSpecialIrpCallDriver+0xcd

FOLLOWUP_IP:
Dbgv+7cc
eb54c7cc eb22 jmp Dbgv+0x7f0 (eb54c7f0)

SYMBOL_STACK_INDEX: 6

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Dbgv+7cc

MODULE_NAME: Dbgv

IMAGE_NAME: Dbgv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3b47213b

STACK_COMMAND: .tss 28 ; kb

BUCKET_ID: 0x7f_8_Dbgv+7cc

Followup: MachineOwner

-----Original Message-----
From: Mats PETERSSON [mailto:xxxxx@3dlabs.com]
Sent: Friday, January 14, 2005 8:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

What does ‘analyze -v’ say?


Mats

-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or
any action taken by you in reliance on it, is prohibited and may be
unlawful. If you have received this message in error, please delete it
and contact the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 01/14/2005 03:03:49 PM:

> I have a BSOD : UNEXPECTED_KERNEL_MODE_TRAP (7f) on my filter driver
> in
W2k.
> I have Driver verify on and below o/p.
> Can not step trace as BSOD is very random and not on every boot
> session. Any Ideas???
> kd> .tss 28
> eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
> eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz
na
po nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
> nt!KiDispatchException+0x25:
> 8042dbbf 53 push ebx
> kd> .trap eb435384
> ErrCode = 00000000
> eax=00000001 ebx=00000000 ecx=eb43542c edx=00000000 esi=00000000
edi=bb050fd0
> eip=8045a9f8 esp=eb4353f8 ebp=eb4353fc iopl=0 nv up ei pl nz
ac
po cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00200217
> nt!DebugService+0x10:
> 8045a9f8 8945fc mov [ebp-0x4],eax
ss:0010:eb4353f8=eb43543c
> kd> !thread
> THREAD 818a1620 Cid 8.20 Teb: 00000000 Win32Thread: 00000000
> RUNNING IRP List:
> bb042e48: (0006,01b4) Flags: 40000884 Mdl: 00000000
> bb038e48: (0006,01b4) Flags: 40000a00 Mdl: 00000000
> Not impersonating
> Owning Process 818a2b60
> Wait Start TickCount 1056281 Elapsed Ticks: 0
> Context Switch Count 54448
> UserTime 0:00:00.0000
> KernelTime 0:00:00.0468
> Start Address nt!ExpWorkerThread (0x80416820)
> Stack Init eb438000 Current eb4357fc Base eb438000 Limit eb435000 Call

> 0 Priority 12 BasePriority 12 PriorityDecrement 0 DecrementCount 0
> kd> kv
> ChildEBP RetAddr Args to Child
> 00000000 8042dbbf 00000000 00000000 00000000 nt!KiTrap08+0x3e (FPO:
> TaskGate 28:0) eb435314 80464891 eb435330 00000000 eb435384 nt!
> KiDispatchException+0x25 (FPO: [Non-Fpo])
> eb43537c 80464e7b 00000000 00000000 00000000 nt!
> CommonDispatchException+0x4d (FPO: [0,20,0])
> eb43537c 8045a9f8 00000000 00000000 00000000 nt!KiTrap03+0x97 (FPO:
> [0,0] TrapFrame @ eb435384) eb4353fc 8045a9c1 00000001 eb43542c
> 00000000 nt!DebugService+0x10
> (FPO: [Non-Fpo])
> eb43540c 80454388 eb43542c bb050fd0 bb050e48 nt!DebugPrint+0xd (FPO:
[1,0,0])
> eb435654 eb54c7cc eb435660 4349440a 746f473a nt!DbgPrint+0xac (FPO:
[Non-Fpo])
> WARNING: Stack unwind information not available. Following frames may
> be wrong. eb435860 f0e7942d f0e78a20 bb050fd0 bb050e48 Dbgv+0x7cc
> eb4359c4 80526626 8135e500 bb050e48 00000000 filespy+0x242d
> eb435a0c bfeee818 00001000 00001000 bfef10fe nt!
> IovSpecialIrpCompleteRequest+0x18c (FPO: [Non-Fpo])
> eb435a18 bfef10fe 81546908 bb050e48 00000000 Ntfs!
> NtfsCompleteRequest+0x5c (FPO: [3,0,2])
> eb435c24 bfef1083 81546908 bb050e48 00000001 Ntfs!
> NtfsCommonRead+0x161a (FPO: [Non-Fpo])
> eb435cc0 805269c4 81810020 bb050e48 81575b50 Ntfs!NtfsFsdRead+0x201
> (FPO: [Non-Fpo])
> eb435d0c f139411b 815d4820 80064bec 805269c4 nt!
> IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
> eb435d64 805261cf bb050fd0 bb050ff4 81488e10 SYMEVENT!
> SYMEvent_GetVMDataPtr+0x697b eb435d80 f0e78828 8135e500 80064bec
> bb050fb4 nt!IovCallDriver+0x31
> (FPO: [Non-Fpo])
> eb435d9c f0e7a994 8135e500 bb050e48 8135e500 filespy+0x1828 eb435db8
> 805269c4 8135e500 bb050e48 8135e500 filespy+0x3994 eb435e04 8041e445
> 00000000 00000000 80064bd4 nt!
> IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
> eb435e18 8043fb41 8169e998 81582ec0 81582ea0 nt!IoPageRead+0xb1
> (FPO: [Non-Fpo])
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument:
‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> ForwardSourceID:NT0000AE32


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

ForwardSourceID:NT0000AE6A

> Just for knowledge :- Could you tell me which part of .tss

output tells us that it’s a double fault case… And why ??

By seeing nt!KiDispatchException, it means NT has encountered a fault or
exception. When KiDispatchException tried to dispatch the exception, it
encountered an other fault by pushing a value into the stack, mainly because
of stack is overflow (you need to verify the esp value and the stack limit
displayed in the !thread command though). That’s a double fault. It’s
handled by a task gate(x86) with its own stack space so that it won’t
tripple fault-:slight_smile:

Also which command will give me amount of stack consumed per function?

Use kf command, alos, you need to dump more frames than default. See my
previous post.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com

From your original message: esp = eb434f78. That’s not in the range
eb438000…eb435000, right?


Mats

xxxxx@lists.osr.com wrote on 01/14/2005 03:38:59 PM:

how Kernel stack overflow possible ?
the Base eb438000 & Limit eb435000
i.e stack range from eb435000 to eb438000.

No stack value is below eb435000 to show a stack over flow…

regards
Anurag
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, January 14, 2005 8:50 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Kernel stack overflow possible.

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

----- Original Message -----
From: Anurag Sarin
To: Windows System Software Devs Interest List
Sent: Friday, January 14, 2005 6:03 PM
Subject: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

I have a BSOD : UNEXPECTED_KERNEL_MODE_TRAP (7f) on my filter driver in
W2k.
I have Driver verify on and below o/p.
Can not step trace as BSOD is very random and not on every boot session.
Any Ideas???
kd> .tss 28
eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx
kd> .trap eb435384
ErrCode = 00000000
eax=00000001 ebx=00000000 ecx=eb43542c edx=00000000 esi=00000000
edi=bb050fd0
eip=8045a9f8 esp=eb4353f8 ebp=eb4353fc iopl=0 nv up ei pl nz ac
po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00200217
nt!DebugService+0x10:
8045a9f8 8945fc mov [ebp-0x4],eax
ss:0010:eb4353f8=eb43543c
kd> !thread
THREAD 818a1620 Cid 8.20 Teb: 00000000 Win32Thread: 00000000 RUNNING
IRP List:
bb042e48: (0006,01b4) Flags: 40000884 Mdl: 00000000
bb038e48: (0006,01b4) Flags: 40000a00 Mdl: 00000000
Not impersonating
Owning Process 818a2b60
Wait Start TickCount 1056281 Elapsed Ticks: 0
Context Switch Count 54448
UserTime 0:00:00.0000
KernelTime 0:00:00.0468
Start Address nt!ExpWorkerThread (0x80416820)
Stack Init eb438000 Current eb4357fc Base eb438000 Limit eb435000 Call 0
Priority 12 BasePriority 12 PriorityDecrement 0 DecrementCount 0
kd> kv
ChildEBP RetAddr Args to Child
00000000 8042dbbf 00000000 00000000 00000000 nt!KiTrap08+0x3e (FPO:
TaskGate 28:0)
eb435314 80464891 eb435330 00000000 eb435384 nt!
KiDispatchException+0x25 (FPO: [Non-Fpo])
eb43537c 80464e7b 00000000 00000000 00000000 nt!
CommonDispatchException+0x4d (FPO: [0,20,0])
eb43537c 8045a9f8 00000000 00000000 00000000 nt!KiTrap03+0x97 (FPO:
[0,0] TrapFrame @ eb435384)
eb4353fc 8045a9c1 00000001 eb43542c 00000000 nt!DebugService+0x10
(FPO: [Non-Fpo])
eb43540c 80454388 eb43542c bb050fd0 bb050e48 nt!DebugPrint+0xd (FPO:
[1,0,0])
eb435654 eb54c7cc eb435660 4349440a 746f473a nt!DbgPrint+0xac (FPO:
[Non-Fpo])
WARNING: Stack unwind information not available. Following frames
may be wrong.
eb435860 f0e7942d f0e78a20 bb050fd0 bb050e48 Dbgv+0x7cc
eb4359c4 80526626 8135e500 bb050e48 00000000 filespy+0x242d
eb435a0c bfeee818 00001000 00001000 bfef10fe nt!
IovSpecialIrpCompleteRequest+0x18c (FPO: [Non-Fpo])
eb435a18 bfef10fe 81546908 bb050e48 00000000 Ntfs!
NtfsCompleteRequest+0x5c (FPO: [3,0,2])
eb435c24 bfef1083 81546908 bb050e48 00000001 Ntfs!
NtfsCommonRead+0x161a (FPO: [Non-Fpo])
eb435cc0 805269c4 81810020 bb050e48 81575b50 Ntfs!NtfsFsdRead+0x201
(FPO: [Non-Fpo])
eb435d0c f139411b 815d4820 80064bec 805269c4 nt!
IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
eb435d64 805261cf bb050fd0 bb050ff4 81488e10 SYMEVENT!
SYMEvent_GetVMDataPtr+0x697b
eb435d80 f0e78828 8135e500 80064bec bb050fb4 nt!IovCallDriver+0x31
(FPO: [Non-Fpo])
eb435d9c f0e7a994 8135e500 bb050e48 8135e500 filespy+0x1828
eb435db8 805269c4 8135e500 bb050e48 8135e500 filespy+0x3994
eb435e04 8041e445 00000000 00000000 80064bd4 nt!
IovSpecialIrpCallDriver+0xcd (FPO: [Non-Fpo])
eb435e18 8043fb41 8169e998 81582ec0 81582ea0 nt!IoPageRead+0xb1
(FPO: [Non-Fpo])

Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT0000AE72

Well, for one thing, you don’t get a TSS if you don’t have a double fault
(or some other fault that the NT kernel developers deemed necessary to make
sure that everything is “fresh” on). A “ordinary” fault is just handled by
a normal trap, whilst a task-state change is needed if you have a “run out
stack” fault, since the normal trap is handled by pushing the relevant data
to the stack, and this doesn’t work if the stack is already full, which
would ensure a triple-fault. In a RTOS I worked on, I had a few instances
of “running out of stack” without a double-fault handler, and that caused
an instant reboot, which is not so great when trying to debug it.


Mats

-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or any
action taken by you in reliance on it, is prohibited and may be unlawful.
If you have received this message in error, please delete it and contact
the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 01/14/2005 03:51:49 PM:

Just for knowledge :- Could you tell me which part of .tss output tells
us that it’s a double fault case… And why ??

Also which command will give me amount of stack consumed per function?

Thanks & Regards
Anurag

-----Original Message-----
From: Calvin Guan [mailto:xxxxx@ati.com]
Sent: Friday, January 14, 2005 8:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

>kd> .tss 28
>eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
>eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz na
po
nc
>cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
>nt!KiDispatchException+0x25:
>8042dbbf 53 push ebx

This is a typical double fault caused by stack overflow.

Check if there’s endless recursion call in the call stack or see which
function consumed abnormal amount of stack. !analyze -v is your first
step to triage.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

ForwardSourceID:NT0000AEAA

The mere fact you are USING the TSS is strongly suggestive of the double
fault case - I’ve never seen any other use of the TSS in Windows (that
doesn’t mean there isn’t one, but I’ve looked at the IDT enough to know
that there aren’t a plethora of TSS selectors in there).

TSS is a hardware (x86) context switching mechanism. One of the reasons
it is employed on the x86 Windows platforms is that it switches to a new
stack. Each processor has a “double fault” stack that is used precisely
in the case where a double fault occurs - because this normally happens
when the stack itself is bad/corrupted/invalid. The TSS (selector) then
forces a hardware context switch to the “new context”. The OLD context
is saved away and processing continues using the NEW context.

The “.tss 28” command says “use the TSS selector at 0x28” and it
displays the information that was stored there (the state of the machine
prior to the switch).

By the way: the double fault switch is ALWAYS one-way. The OS doesn’t
come back from this switch. So no matter the cause of the switch, it is
terminal.

Regards,

Tony

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

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Friday, January 14, 2005 10:52 AM
To: ntdev redirect
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Just for knowledge :- Could you tell me which part of .tss output tells
us that it’s a double fault case… And why ??

Also which command will give me amount of stack consumed per function?

Thanks & Regards
Anurag

-----Original Message-----
From: Calvin Guan [mailto:xxxxx@ati.com]
Sent: Friday, January 14, 2005 8:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

kd> .tss 28
eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz na
po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx

This is a typical double fault caused by stack overflow.

Check if there’s endless recursion call in the call stack or see which
function consumed abnormal amount of stack. !analyze -v is your first
step to triage.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Thanks Calvin, Matt and all for your prompt inputs. I am convinced that
it’s a stack over flow and have learnt a lot.

Now I have the possibilities
1>A recursion
2>abnormal sum of Memory on stack

I am trying to figure out where is code going on recursion.

For the second possibility I would like to know How much of memory is
abnormal memory for the stack ?
I have big chunks like 3bc , 248, 210 , 37c etc…

Like I have kf output as follows.

kd> kf 50
Memory ChildEBP RetAddr
00000000 8042d3c5 nt!KiTrap08+0x3e
eb43502c eb43502c 8042dc13 nt!KeContextFromKframes+0x9
3bc eb4353e8 80464891 nt!KiDispatchException+0x79
68 eb435450 80464e7b nt!CommonDispatchException+0x4d
0 eb435450 8045a9f8 nt!KiTrap03+0x97
80 eb4354d0 8045a9c1 nt!DebugService+0x10
10 eb4354e0 80454388 nt!DebugPrint+0xd
248 eb435728 eb5387ef nt!DbgPrint+0xac
WARNING: Stack unwind information not available. Following frames may be
wrong.
210 eb435938 f0e02e7e Dbgv+0x7ef
c eb435944 80526626 filespy!Completion_EZ_SetInfo+0x3f
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 4444]
48 eb43598c bfeee818 nt!IovSpecialIrpCompleteRequest+0x18c
c eb435998 bfeef6bd Ntfs!NtfsCompleteRequest+0x5c
37c eb435d14 bfeee3e8 Ntfs!NtfsCommonWrite+0x2b02
68 eb435d7c 805269c4 Ntfs!NtfsFsdWrite+0xee
4c eb435dc8 f136c184 nt!IovSpecialIrpCallDriver+0xcd
b0 eb435e78 805261cf SYMEVENT!SYMEvent_GetVMDataPtr+0x69e4
1c eb435e94 f0dffa0c nt!IovCallDriver+0x31
1c eb435eb0 f0e0864e filespy!SpyPassThrough_EZ_Write+0x102
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 2547]
16c eb43601c 805269c4 filespy!SpyWrite+0x1822
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 11623]
4c eb436068 8041ea32 nt!IovSpecialIrpCallDriver+0xcd
14 eb43607c 8043c9fe nt!IoSynchronousPageWrite+0xa6
d0 eb43614c 8043c50b nt!MiFlushSectionInternal+0x392
40 eb43618c 8040ea6e nt!MmFlushSection+0x1c9
dc eb436268 bff17334 nt!CcFlushCache+0x3f4
10c eb436374 bff17609 Ntfs!LfsFlushLfcb+0x3d4
24 eb436398 bff167cb Ntfs!LfsFlushLbcb+0x9e
28 eb4363c0 bff166e2 Ntfs!LfsFlushToLsnPriv+0xf7
4c eb43640c bff21d12 Ntfs!LfsFlushToLsn+0xb2
34 eb436440 bfeefe0c Ntfs!NtfsCommitCurrentTransaction+0x1ec
10 eb436450 bff0f3ee Ntfs!NtfsCompleteRequest+0x1a
2ec eb43673c bff0c5a2 Ntfs!NtfsCommonCreate+0xe82
b4 eb4367f0 805269c4 Ntfs!NtfsFsdCreate+0x1fe
4c eb43683c f136c273 nt!IovSpecialIrpCallDriver+0xcd
b8 eb4368f4 805261cf SYMEVENT!SYMEvent_GetVMDataPtr+0x6ad3
1c eb436910 f0dffbfc nt!IovCallDriver+0x31
1c eb43692c f0e04d47 filespy!SpyPassThrough_EZ_Create+0x102
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 2595]
90 eb4369bc 805269c4 filespy!SpyCreate+0x597
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 5329]
4c eb436a08 804bda04 nt!IovSpecialIrpCallDriver+0xcd
190 eb436b98 8044f5b5 nt!IopParseDevice+0xab4
78 eb436c10 804d378b nt!ObpLookupObjectName+0x4e7
110 eb436d20 8049dd31 nt!ObOpenObjectByName+0xc5
dc eb436dfc 8049d8d6 nt!IopCreateFile+0x407
48 eb436e44 804a5264 nt!IoCreateFile+0x36
40 eb436e84 80463d94 nt!NtCreateFile+0x2e
0 eb436e84 8042e953 nt!KiSystemService+0xc4
a4 eb436f28 f0e088e2 nt!ZwCreateFile+0xb
190 eb4370b8 805269c4 filespy!SpyWrite+0x1ab6
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 11729]
4c eb437104 804aca56 nt!IovSpecialIrpCallDriver+0xcd
14 eb437118 804a9b99 nt!IopSynchronousServiceTail+0x60
e8 eb437200 80463d94 nt!NtWriteFile+0x657
0 eb437200 8042f613 nt!KiSystemService+0xc4
9c eb43729c 8052071f nt!ZwWriteFile+0xb
a50 eb437cec 8051da22 nt!CmpFileWrite+0x14d
58 eb437d44 8051d6f6 nt!HvpWriteLog+0x90
10 eb437d54 80518036 nt!HvSyncHive+0x38
1c eb437d70 80516dfc nt!CmpDoFlushAll+0x4c
8 eb437d78 804168ce nt!CmpLazyFlushWorker+0x16
30 eb437da8 80453844 nt!ExpWorkerThread+0xae
34 eb437ddc 80468022 nt!PspSystemThreadStartup+0x54
00000000 00000000 nt!KiThreadStartup+0x16

Regards
Anurag

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Friday, January 14, 2005 10:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

The mere fact you are USING the TSS is strongly suggestive of the double
fault case - I’ve never seen any other use of the TSS in Windows (that
doesn’t mean there isn’t one, but I’ve looked at the IDT enough to know
that there aren’t a plethora of TSS selectors in there).

TSS is a hardware (x86) context switching mechanism. One of the reasons
it is employed on the x86 Windows platforms is that it switches to a new
stack. Each processor has a “double fault” stack that is used precisely
in the case where a double fault occurs - because this normally happens
when the stack itself is bad/corrupted/invalid. The TSS (selector) then
forces a hardware context switch to the “new context”. The OLD context
is saved away and processing continues using the NEW context.

The “.tss 28” command says “use the TSS selector at 0x28” and it
displays the information that was stored there (the state of the machine
prior to the switch).

By the way: the double fault switch is ALWAYS one-way. The OS doesn’t
come back from this switch. So no matter the cause of the switch, it is
terminal.

Regards,

Tony

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

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Friday, January 14, 2005 10:52 AM
To: ntdev redirect
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Just for knowledge :- Could you tell me which part of .tss output tells
us that it’s a double fault case… And why ??

Also which command will give me amount of stack consumed per function?

Thanks & Regards
Anurag

-----Original Message-----
From: Calvin Guan [mailto:xxxxx@ati.com]
Sent: Friday, January 14, 2005 8:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

kd> .tss 28
eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz na
po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
nt!KiDispatchException+0x25:
8042dbbf 53 push ebx

This is a typical double fault caused by stack overflow.

Check if there’s endless recursion call in the call stack or see which
function consumed abnormal amount of stack. !analyze -v is your first
step to triage.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com

Calling createfile inline in the write path is probably not a good idea. Nor
is allocating anything other than small data structures on the stack going
to work. What is small? A very good question, I’m glad you asked. Objects on
the order of 1000 bytes are definitely not small, given the kernel stack
size.

You are inside your 4th level of filespy recursion at the point of the
crash. By this time, given this discussion, that ought to be telling you IN
HUGE BOLDFACE ALL CAP FONTS that you have a serious design problem.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Friday, January 14, 2005 3:04 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Thanks Calvin, Matt and all for your prompt inputs. I am
convinced that it’s a stack over flow and have learnt a lot.

Now I have the possibilities
1>A recursion
2>abnormal sum of Memory on stack

I am trying to figure out where is code going on recursion.

For the second possibility I would like to know How much of
memory is abnormal memory for the stack ?
I have big chunks like 3bc , 248, 210 , 37c etc…

Like I have kf output as follows.

kd> kf 50
Memory ChildEBP RetAddr
00000000 8042d3c5 nt!KiTrap08+0x3e eb43502c eb43502c
8042dc13 nt!KeContextFromKframes+0x9
3bc eb4353e8 80464891 nt!KiDispatchException+0x79
68 eb435450 80464e7b nt!CommonDispatchException+0x4d
0 eb435450 8045a9f8 nt!KiTrap03+0x97
80 eb4354d0 8045a9c1 nt!DebugService+0x10
10 eb4354e0 80454388 nt!DebugPrint+0xd
248 eb435728 eb5387ef nt!DbgPrint+0xac
WARNING: Stack unwind information not available. Following
frames may be wrong.
210 eb435938 f0e02e7e Dbgv+0x7ef
c eb435944 80526626 filespy!Completion_EZ_SetInfo+0x3f
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 4444]
48 eb43598c bfeee818 nt!IovSpecialIrpCompleteRequest+0x18c
c eb435998 bfeef6bd Ntfs!NtfsCompleteRequest+0x5c
37c eb435d14 bfeee3e8 Ntfs!NtfsCommonWrite+0x2b02
68 eb435d7c 805269c4 Ntfs!NtfsFsdWrite+0xee
4c eb435dc8 f136c184 nt!IovSpecialIrpCallDriver+0xcd
b0 eb435e78 805261cf SYMEVENT!SYMEvent_GetVMDataPtr+0x69e4
1c eb435e94 f0dffa0c nt!IovCallDriver+0x31
1c eb435eb0 f0e0864e filespy!SpyPassThrough_EZ_Write+0x102
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 2547]
16c eb43601c 805269c4 filespy!SpyWrite+0x1822
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 11623]
4c eb436068 8041ea32 nt!IovSpecialIrpCallDriver+0xcd
14 eb43607c 8043c9fe nt!IoSynchronousPageWrite+0xa6
d0 eb43614c 8043c50b nt!MiFlushSectionInternal+0x392
40 eb43618c 8040ea6e nt!MmFlushSection+0x1c9
dc eb436268 bff17334 nt!CcFlushCache+0x3f4
10c eb436374 bff17609 Ntfs!LfsFlushLfcb+0x3d4
24 eb436398 bff167cb Ntfs!LfsFlushLbcb+0x9e
28 eb4363c0 bff166e2 Ntfs!LfsFlushToLsnPriv+0xf7
4c eb43640c bff21d12 Ntfs!LfsFlushToLsn+0xb2
34 eb436440 bfeefe0c Ntfs!NtfsCommitCurrentTransaction+0x1ec
10 eb436450 bff0f3ee Ntfs!NtfsCompleteRequest+0x1a
2ec eb43673c bff0c5a2 Ntfs!NtfsCommonCreate+0xe82
b4 eb4367f0 805269c4 Ntfs!NtfsFsdCreate+0x1fe
4c eb43683c f136c273 nt!IovSpecialIrpCallDriver+0xcd
b8 eb4368f4 805261cf SYMEVENT!SYMEvent_GetVMDataPtr+0x6ad3
1c eb436910 f0dffbfc nt!IovCallDriver+0x31
1c eb43692c f0e04d47 filespy!SpyPassThrough_EZ_Create+0x102
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 2595]
90 eb4369bc 805269c4 filespy!SpyCreate+0x597
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 5329]
4c eb436a08 804bda04 nt!IovSpecialIrpCallDriver+0xcd
190 eb436b98 8044f5b5 nt!IopParseDevice+0xab4
78 eb436c10 804d378b nt!ObpLookupObjectName+0x4e7
110 eb436d20 8049dd31 nt!ObOpenObjectByName+0xc5
dc eb436dfc 8049d8d6 nt!IopCreateFile+0x407
48 eb436e44 804a5264 nt!IoCreateFile+0x36
40 eb436e84 80463d94 nt!NtCreateFile+0x2e
0 eb436e84 8042e953 nt!KiSystemService+0xc4
a4 eb436f28 f0e088e2 nt!ZwCreateFile+0xb
190 eb4370b8 805269c4 filespy!SpyWrite+0x1ab6
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 11729]
4c eb437104 804aca56 nt!IovSpecialIrpCallDriver+0xcd
14 eb437118 804a9b99 nt!IopSynchronousServiceTail+0x60
e8 eb437200 80463d94 nt!NtWriteFile+0x657
0 eb437200 8042f613 nt!KiSystemService+0xc4
9c eb43729c 8052071f nt!ZwWriteFile+0xb
a50 eb437cec 8051da22 nt!CmpFileWrite+0x14d
58 eb437d44 8051d6f6 nt!HvpWriteLog+0x90
10 eb437d54 80518036 nt!HvSyncHive+0x38
1c eb437d70 80516dfc nt!CmpDoFlushAll+0x4c
8 eb437d78 804168ce nt!CmpLazyFlushWorker+0x16
30 eb437da8 80453844 nt!ExpWorkerThread+0xae
34 eb437ddc 80468022 nt!PspSystemThreadStartup+0x54
00000000 00000000 nt!KiThreadStartup+0x16

Regards
Anurag

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Friday, January 14, 2005 10:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

The mere fact you are USING the TSS is strongly suggestive of
the double
fault case - I’ve never seen any other use of the TSS in Windows (that
doesn’t mean there isn’t one, but I’ve looked at the IDT
enough to know
that there aren’t a plethora of TSS selectors in there).

TSS is a hardware (x86) context switching mechanism. One of
the reasons
it is employed on the x86 Windows platforms is that it
switches to a new
stack. Each processor has a “double fault” stack that is
used precisely
in the case where a double fault occurs - because this
normally happens
when the stack itself is bad/corrupted/invalid. The TSS
(selector) then
forces a hardware context switch to the “new context”. The
OLD context
is saved away and processing continues using the NEW context.

The “.tss 28” command says “use the TSS selector at 0x28” and it
displays the information that was stored there (the state of
the machine
prior to the switch).

By the way: the double fault switch is ALWAYS one-way. The OS doesn’t
come back from this switch. So no matter the cause of the
switch, it is
terminal.

Regards,

Tony

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

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Friday, January 14, 2005 10:52 AM
To: ntdev redirect
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Just for knowledge :- Could you tell me which part of .tss
output tells
us that it’s a double fault case… And why ??

Also which command will give me amount of stack consumed per function?

Thanks & Regards
Anurag

-----Original Message-----
From: Calvin Guan [mailto:xxxxx@ati.com]
Sent: Friday, January 14, 2005 8:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

>kd> .tss 28
>eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
>eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up
di ng nz na
po
nc
>cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
>nt!KiDispatchException+0x25:
>8042dbbf 53 push ebx

This is a typical double fault caused by stack overflow.

Check if there’s endless recursion call in the call stack or see which
function consumed abnormal amount of stack. !analyze -v is your first
step to triage.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’ To unsubscribe send a blank email to
xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’ To unsubscribe send a blank email to
xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Mark,

I suppose “Calling createfile inline in the write path is probably not a
good idea” because of Re-entrancy reasons , hence giving recursion. Am I
right ?

So what can be an alternative for ZwCreateFile and ZwWriteFile to be
called in Write dispatch routine ?

Also for knowledge : from the stack trace below , how to find out that I
am in 4 Stage of recursion. As there are FileSpy functions but are
different function , how to know that the same function is been called 4
times… ???

Thanks
Anurag

-----Original Message-----
From: Mark Roddy [mailto:xxxxx@hollistech.com]
Sent: Saturday, January 15, 2005 2:01 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Calling createfile inline in the write path is probably not a good idea.
Nor is allocating anything other than small data structures on the stack
going to work. What is small? A very good question, I’m glad you asked.
Objects on the order of 1000 bytes are definitely not small, given the
kernel stack size.

You are inside your 4th level of filespy recursion at the point of the
crash. By this time, given this discussion, that ought to be telling you
IN HUGE BOLDFACE ALL CAP FONTS that you have a serious design problem.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Friday, January 14, 2005 3:04 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Thanks Calvin, Matt and all for your prompt inputs. I am convinced
that it’s a stack over flow and have learnt a lot.

Now I have the possibilities
1>A recursion
2>abnormal sum of Memory on stack

I am trying to figure out where is code going on recursion.

For the second possibility I would like to know How much of memory is
abnormal memory for the stack ? I have big chunks like 3bc , 248, 210
, 37c etc…

Like I have kf output as follows.

kd> kf 50
Memory ChildEBP RetAddr
00000000 8042d3c5 nt!KiTrap08+0x3e eb43502c eb43502c 8042dc13

nt!KeContextFromKframes+0x9
3bc eb4353e8 80464891 nt!KiDispatchException+0x79
68 eb435450 80464e7b nt!CommonDispatchException+0x4d
0 eb435450 8045a9f8 nt!KiTrap03+0x97
80 eb4354d0 8045a9c1 nt!DebugService+0x10
10 eb4354e0 80454388 nt!DebugPrint+0xd
248 eb435728 eb5387ef nt!DbgPrint+0xac
WARNING: Stack unwind information not available. Following
frames may be wrong.
210 eb435938 f0e02e7e Dbgv+0x7ef
c eb435944 80526626 filespy!Completion_EZ_SetInfo+0x3f
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 4444]
48 eb43598c bfeee818 nt!IovSpecialIrpCompleteRequest+0x18c
c eb435998 bfeef6bd Ntfs!NtfsCompleteRequest+0x5c
37c eb435d14 bfeee3e8 Ntfs!NtfsCommonWrite+0x2b02
68 eb435d7c 805269c4 Ntfs!NtfsFsdWrite+0xee
4c eb435dc8 f136c184 nt!IovSpecialIrpCallDriver+0xcd
b0 eb435e78 805261cf SYMEVENT!SYMEvent_GetVMDataPtr+0x69e4
1c eb435e94 f0dffa0c nt!IovCallDriver+0x31
1c eb435eb0 f0e0864e filespy!SpyPassThrough_EZ_Write+0x102
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 2547]
16c eb43601c 805269c4 filespy!SpyWrite+0x1822
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 11623]
4c eb436068 8041ea32 nt!IovSpecialIrpCallDriver+0xcd
14 eb43607c 8043c9fe nt!IoSynchronousPageWrite+0xa6
d0 eb43614c 8043c50b nt!MiFlushSectionInternal+0x392
40 eb43618c 8040ea6e nt!MmFlushSection+0x1c9
dc eb436268 bff17334 nt!CcFlushCache+0x3f4
10c eb436374 bff17609 Ntfs!LfsFlushLfcb+0x3d4
24 eb436398 bff167cb Ntfs!LfsFlushLbcb+0x9e
28 eb4363c0 bff166e2 Ntfs!LfsFlushToLsnPriv+0xf7
4c eb43640c bff21d12 Ntfs!LfsFlushToLsn+0xb2
34 eb436440 bfeefe0c Ntfs!NtfsCommitCurrentTransaction+0x1ec
10 eb436450 bff0f3ee Ntfs!NtfsCompleteRequest+0x1a
2ec eb43673c bff0c5a2 Ntfs!NtfsCommonCreate+0xe82
b4 eb4367f0 805269c4 Ntfs!NtfsFsdCreate+0x1fe
4c eb43683c f136c273 nt!IovSpecialIrpCallDriver+0xcd
b8 eb4368f4 805261cf SYMEVENT!SYMEvent_GetVMDataPtr+0x6ad3
1c eb436910 f0dffbfc nt!IovCallDriver+0x31
1c eb43692c f0e04d47 filespy!SpyPassThrough_EZ_Create+0x102
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 2595]
90 eb4369bc 805269c4 filespy!SpyCreate+0x597
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 5329]
4c eb436a08 804bda04 nt!IovSpecialIrpCallDriver+0xcd
190 eb436b98 8044f5b5 nt!IopParseDevice+0xab4
78 eb436c10 804d378b nt!ObpLookupObjectName+0x4e7
110 eb436d20 8049dd31 nt!ObOpenObjectByName+0xc5
dc eb436dfc 8049d8d6 nt!IopCreateFile+0x407
48 eb436e44 804a5264 nt!IoCreateFile+0x36
40 eb436e84 80463d94 nt!NtCreateFile+0x2e
0 eb436e84 8042e953 nt!KiSystemService+0xc4
a4 eb436f28 f0e088e2 nt!ZwCreateFile+0xb
190 eb4370b8 805269c4 filespy!SpyWrite+0x1ab6
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 11729]
4c eb437104 804aca56 nt!IovSpecialIrpCallDriver+0xcd
14 eb437118 804a9b99 nt!IopSynchronousServiceTail+0x60
e8 eb437200 80463d94 nt!NtWriteFile+0x657
0 eb437200 8042f613 nt!KiSystemService+0xc4
9c eb43729c 8052071f nt!ZwWriteFile+0xb
a50 eb437cec 8051da22 nt!CmpFileWrite+0x14d
58 eb437d44 8051d6f6 nt!HvpWriteLog+0x90
10 eb437d54 80518036 nt!HvSyncHive+0x38
1c eb437d70 80516dfc nt!CmpDoFlushAll+0x4c
8 eb437d78 804168ce nt!CmpLazyFlushWorker+0x16
30 eb437da8 80453844 nt!ExpWorkerThread+0xae
34 eb437ddc 80468022 nt!PspSystemThreadStartup+0x54
00000000 00000000 nt!KiThreadStartup+0x16

Regards
Anurag

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Friday, January 14, 2005 10:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

The mere fact you are USING the TSS is strongly suggestive of the
double fault case - I’ve never seen any other use of the TSS in
Windows (that doesn’t mean there isn’t one, but I’ve looked at the IDT
enough to know
that there aren’t a plethora of TSS selectors in there).

TSS is a hardware (x86) context switching mechanism. One of the
reasons it is employed on the x86 Windows platforms is that it
switches to a new
stack. Each processor has a “double fault” stack that is
used precisely
in the case where a double fault occurs - because this
normally happens
when the stack itself is bad/corrupted/invalid. The TSS
(selector) then
forces a hardware context switch to the “new context”. The
OLD context
is saved away and processing continues using the NEW context.

The “.tss 28” command says “use the TSS selector at 0x28” and it
displays the information that was stored there (the state of the
machine prior to the switch).

By the way: the double fault switch is ALWAYS one-way. The OS doesn’t
come back from this switch. So no matter the cause of the switch, it
is terminal.

Regards,

Tony

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

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Friday, January 14, 2005 10:52 AM
To: ntdev redirect
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Just for knowledge :- Could you tell me which part of .tss output
tells us that it’s a double fault case… And why ??

Also which command will give me amount of stack consumed per function?

Thanks & Regards
Anurag

-----Original Message-----
From: Calvin Guan [mailto:xxxxx@ati.com]
Sent: Friday, January 14, 2005 8:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

>kd> .tss 28
>eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
>eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up
di ng nz na
po
nc
>cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
>nt!KiDispatchException+0x25:
>8042dbbf 53 push ebx

This is a typical double fault caused by stack overflow.

Check if there’s endless recursion call in the call stack or see which
function consumed abnormal amount of stack. !analyze -v is your first
step to triage.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’ To unsubscribe send a blank email to
xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’ To unsubscribe send a blank email to
xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Mark,

I suppose “Calling createfile inline in the write path is probably not a
good idea” because of Re-entrancy reasons , hence giving recursion. Am I
right ?

So what can be an alternative for ZwCreateFile and ZwWriteFile to be
called in Write dispatch routine ?

Also for knowledge : from the stack trace below , how to find out that I
am in 4 Stage of recursion. As there are FileSpy functions but are
different function , how to know that the same function is been called 4
times… ???

Thanks
Anurag

-----Original Message-----
From: Mark Roddy [mailto:xxxxx@hollistech.com]
Sent: Saturday, January 15, 2005 2:01 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Calling createfile inline in the write path is probably not a good idea.
Nor is allocating anything other than small data structures on the stack
going to work. What is small? A very good question, I’m glad you asked.
Objects on the order of 1000 bytes are definitely not small, given the
kernel stack size.

You are inside your 4th level of filespy recursion at the point of the
crash. By this time, given this discussion, that ought to be telling you
IN HUGE BOLDFACE ALL CAP FONTS that you have a serious design problem.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Friday, January 14, 2005 3:04 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Thanks Calvin, Matt and all for your prompt inputs. I am convinced
that it’s a stack over flow and have learnt a lot.

Now I have the possibilities
1>A recursion
2>abnormal sum of Memory on stack

I am trying to figure out where is code going on recursion.

For the second possibility I would like to know How much of memory is
abnormal memory for the stack ? I have big chunks like 3bc , 248, 210
, 37c etc…

Like I have kf output as follows.

kd> kf 50
Memory ChildEBP RetAddr
00000000 8042d3c5 nt!KiTrap08+0x3e eb43502c eb43502c 8042dc13
nt!KeContextFromKframes+0x9
3bc eb4353e8 80464891 nt!KiDispatchException+0x79
68 eb435450 80464e7b nt!CommonDispatchException+0x4d
0 eb435450 8045a9f8 nt!KiTrap03+0x97
80 eb4354d0 8045a9c1 nt!DebugService+0x10
10 eb4354e0 80454388 nt!DebugPrint+0xd
248 eb435728 eb5387ef nt!DbgPrint+0xac
WARNING: Stack unwind information not available. Following
frames may be wrong.
210 eb435938 f0e02e7e Dbgv+0x7ef
c eb435944 80526626 filespy!Completion_EZ_SetInfo+0x3f
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 4444]
48 eb43598c bfeee818 nt!IovSpecialIrpCompleteRequest+0x18c
c eb435998 bfeef6bd Ntfs!NtfsCompleteRequest+0x5c
37c eb435d14 bfeee3e8 Ntfs!NtfsCommonWrite+0x2b02
68 eb435d7c 805269c4 Ntfs!NtfsFsdWrite+0xee
4c eb435dc8 f136c184 nt!IovSpecialIrpCallDriver+0xcd
b0 eb435e78 805261cf SYMEVENT!SYMEvent_GetVMDataPtr+0x69e4
1c eb435e94 f0dffa0c nt!IovCallDriver+0x31
1c eb435eb0 f0e0864e filespy!SpyPassThrough_EZ_Write+0x102
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 2547]
16c eb43601c 805269c4 filespy!SpyWrite+0x1822
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 11623]
4c eb436068 8041ea32 nt!IovSpecialIrpCallDriver+0xcd
14 eb43607c 8043c9fe nt!IoSynchronousPageWrite+0xa6
d0 eb43614c 8043c50b nt!MiFlushSectionInternal+0x392
40 eb43618c 8040ea6e nt!MmFlushSection+0x1c9
dc eb436268 bff17334 nt!CcFlushCache+0x3f4
10c eb436374 bff17609 Ntfs!LfsFlushLfcb+0x3d4
24 eb436398 bff167cb Ntfs!LfsFlushLbcb+0x9e
28 eb4363c0 bff166e2 Ntfs!LfsFlushToLsnPriv+0xf7
4c eb43640c bff21d12 Ntfs!LfsFlushToLsn+0xb2
34 eb436440 bfeefe0c Ntfs!NtfsCommitCurrentTransaction+0x1ec
10 eb436450 bff0f3ee Ntfs!NtfsCompleteRequest+0x1a
2ec eb43673c bff0c5a2 Ntfs!NtfsCommonCreate+0xe82
b4 eb4367f0 805269c4 Ntfs!NtfsFsdCreate+0x1fe
4c eb43683c f136c273 nt!IovSpecialIrpCallDriver+0xcd
b8 eb4368f4 805261cf SYMEVENT!SYMEvent_GetVMDataPtr+0x6ad3
1c eb436910 f0dffbfc nt!IovCallDriver+0x31
1c eb43692c f0e04d47 filespy!SpyPassThrough_EZ_Create+0x102
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 2595]
90 eb4369bc 805269c4 filespy!SpyCreate+0x597
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 5329]
4c eb436a08 804bda04 nt!IovSpecialIrpCallDriver+0xcd
190 eb436b98 8044f5b5 nt!IopParseDevice+0xab4
78 eb436c10 804d378b nt!ObpLookupObjectName+0x4e7
110 eb436d20 8049dd31 nt!ObOpenObjectByName+0xc5
dc eb436dfc 8049d8d6 nt!IopCreateFile+0x407
48 eb436e44 804a5264 nt!IoCreateFile+0x36
40 eb436e84 80463d94 nt!NtCreateFile+0x2e
0 eb436e84 8042e953 nt!KiSystemService+0xc4
a4 eb436f28 f0e088e2 nt!ZwCreateFile+0xb
190 eb4370b8 805269c4 filespy!SpyWrite+0x1ab6
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 11729]
4c eb437104 804aca56 nt!IovSpecialIrpCallDriver+0xcd
14 eb437118 804a9b99 nt!IopSynchronousServiceTail+0x60
e8 eb437200 80463d94 nt!NtWriteFile+0x657
0 eb437200 8042f613 nt!KiSystemService+0xc4
9c eb43729c 8052071f nt!ZwWriteFile+0xb
a50 eb437cec 8051da22 nt!CmpFileWrite+0x14d
58 eb437d44 8051d6f6 nt!HvpWriteLog+0x90
10 eb437d54 80518036 nt!HvSyncHive+0x38
1c eb437d70 80516dfc nt!CmpDoFlushAll+0x4c
8 eb437d78 804168ce nt!CmpLazyFlushWorker+0x16
30 eb437da8 80453844 nt!ExpWorkerThread+0xae
34 eb437ddc 80468022 nt!PspSystemThreadStartup+0x54
00000000 00000000 nt!KiThreadStartup+0x16

Regards
Anurag

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Friday, January 14, 2005 10:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

The mere fact you are USING the TSS is strongly suggestive of the
double fault case - I’ve never seen any other use of the TSS in
Windows (that doesn’t mean there isn’t one, but I’ve looked at the IDT
enough to know
that there aren’t a plethora of TSS selectors in there).

TSS is a hardware (x86) context switching mechanism. One of the
reasons it is employed on the x86 Windows platforms is that it
switches to a new
stack. Each processor has a “double fault” stack that is
used precisely
in the case where a double fault occurs - because this
normally happens
when the stack itself is bad/corrupted/invalid. The TSS
(selector) then
forces a hardware context switch to the “new context”. The
OLD context
is saved away and processing continues using the NEW context.

The “.tss 28” command says “use the TSS selector at 0x28” and it
displays the information that was stored there (the state of the
machine prior to the switch).

By the way: the double fault switch is ALWAYS one-way. The OS doesn’t

come back from this switch. So no matter the cause of the switch, it
is terminal.

Regards,

Tony

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

Looking forward to seeing you at the Next OSR File Systems Class April

4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Friday, January 14, 2005 10:52 AM
To: ntdev redirect
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Just for knowledge :- Could you tell me which part of .tss output
tells us that it’s a double fault case… And why ??

Also which command will give me amount of stack consumed per function?

Thanks & Regards
Anurag

-----Original Message-----
From: Calvin Guan [mailto:xxxxx@ati.com]
Sent: Friday, January 14, 2005 8:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

>kd> .tss 28
>eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
>eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up
di ng nz na
po
nc
>cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
>nt!KiDispatchException+0x25:
>8042dbbf 53 push ebx

This is a typical double fault caused by stack overflow.

Check if there’s endless recursion call in the call stack or see which

function consumed abnormal amount of stack. !analyze -v is your first
step to triage.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’ To unsubscribe send a blank email to
xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument:
‘’ To unsubscribe send a blank email to
xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

By ‘4 levels of recursion into filespy’ I mean into the driver, not
neccesarilly into the same function. The fact that there are four separate
groups of filespy stack entries in the stack trace indicates that your
design is rather wrong. As for the rest of it, well this the ntdev list, and
you have a file system filter driver problem. You might consider going over
to the filesystem list and asking them for help.

Concerning your other recent posts, I’m sorry that your colleagues left you
with this mess. You are not the first to be stuck with a hopeless project
abandoned by others who have fled for safer waters. The good news is that
you are free to point out what a mess they have made. The bad news is that
nobody is likely to listen, and ultimately you will get the blame, unless
you also manage to extricate yourself either by an heroic act of programming
or by following in your colleagues footsteps. This would be a good time to
campaign internally for a scrap and restart.

As you noted I am a consultant. If you would like me to consult on your
project, rather than offer the bits of advice, (and the occasional offhand
insults,) that I provide here, that can be arranged. My family needs to eat
too.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Saturday, January 15, 2005 5:52 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Mark,

I suppose “Calling createfile inline in the write path is
probably not a good idea” because of Re-entrancy reasons ,
hence giving recursion. Am I right ?

So what can be an alternative for ZwCreateFile and
ZwWriteFile to be called in Write dispatch routine ?

Also for knowledge : from the stack trace below , how to find
out that I am in 4 Stage of recursion. As there are FileSpy
functions but are different function , how to know that the
same function is been called 4 times… ???

Thanks
Anurag

-----Original Message-----
From: Mark Roddy [mailto:xxxxx@hollistech.com]
Sent: Saturday, January 15, 2005 2:01 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Calling createfile inline in the write path is probably not a
good idea.
Nor is allocating anything other than small data structures
on the stack
going to work. What is small? A very good question, I’m glad
you asked.
Objects on the order of 1000 bytes are definitely not small, given the
kernel stack size.

You are inside your 4th level of filespy recursion at the point of the
crash. By this time, given this discussion, that ought to be
telling you
IN HUGE BOLDFACE ALL CAP FONTS that you have a serious design problem.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
> Sent: Friday, January 14, 2005 3:04 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)
>
> Thanks Calvin, Matt and all for your prompt inputs. I am convinced
> that it’s a stack over flow and have learnt a lot.
>
> Now I have the possibilities
> 1>A recursion
> 2>abnormal sum of Memory on stack
>
> I am trying to figure out where is code going on recursion.
>
> For the second possibility I would like to know How much of
memory is
> abnormal memory for the stack ? I have big chunks like 3bc
, 248, 210
> , 37c etc…
>
> Like I have kf output as follows.
>
> kd> kf 50
> Memory ChildEBP RetAddr
> 00000000 8042d3c5 nt!KiTrap08+0x3e eb43502c
eb43502c 8042dc13

> nt!KeContextFromKframes+0x9
> 3bc eb4353e8 80464891 nt!KiDispatchException+0x79
> 68 eb435450 80464e7b nt!CommonDispatchException+0x4d
> 0 eb435450 8045a9f8 nt!KiTrap03+0x97
> 80 eb4354d0 8045a9c1 nt!DebugService+0x10
> 10 eb4354e0 80454388 nt!DebugPrint+0xd
> 248 eb435728 eb5387ef nt!DbgPrint+0xac
> WARNING: Stack unwind information not available. Following
> frames may be wrong.
> 210 eb435938 f0e02e7e Dbgv+0x7ef
> c eb435944 80526626 filespy!Completion_EZ_SetInfo+0x3f
> [c:\kernelcode\kernelworkspace\filter\filespy.c @ 4444]
> 48 eb43598c bfeee818 nt!IovSpecialIrpCompleteRequest+0x18c
> c eb435998 bfeef6bd Ntfs!NtfsCompleteRequest+0x5c
> 37c eb435d14 bfeee3e8 Ntfs!NtfsCommonWrite+0x2b02
> 68 eb435d7c 805269c4 Ntfs!NtfsFsdWrite+0xee
> 4c eb435dc8 f136c184 nt!IovSpecialIrpCallDriver+0xcd
> b0 eb435e78 805261cf SYMEVENT!SYMEvent_GetVMDataPtr+0x69e4
> 1c eb435e94 f0dffa0c nt!IovCallDriver+0x31
> 1c eb435eb0 f0e0864e filespy!SpyPassThrough_EZ_Write+0x102
> [c:\kernelcode\kernelworkspace\filter\filespy.c @ 2547]
> 16c eb43601c 805269c4 filespy!SpyWrite+0x1822
> [c:\kernelcode\kernelworkspace\filter\filespy.c @ 11623]
> 4c eb436068 8041ea32 nt!IovSpecialIrpCallDriver+0xcd
> 14 eb43607c 8043c9fe nt!IoSynchronousPageWrite+0xa6
> d0 eb43614c 8043c50b nt!MiFlushSectionInternal+0x392
> 40 eb43618c 8040ea6e nt!MmFlushSection+0x1c9
> dc eb436268 bff17334 nt!CcFlushCache+0x3f4
> 10c eb436374 bff17609 Ntfs!LfsFlushLfcb+0x3d4
> 24 eb436398 bff167cb Ntfs!LfsFlushLbcb+0x9e
> 28 eb4363c0 bff166e2 Ntfs!LfsFlushToLsnPriv+0xf7
> 4c eb43640c bff21d12 Ntfs!LfsFlushToLsn+0xb2
> 34 eb436440 bfeefe0c Ntfs!NtfsCommitCurrentTransaction+0x1ec
> 10 eb436450 bff0f3ee Ntfs!NtfsCompleteRequest+0x1a
> 2ec eb43673c bff0c5a2 Ntfs!NtfsCommonCreate+0xe82
> b4 eb4367f0 805269c4 Ntfs!NtfsFsdCreate+0x1fe
> 4c eb43683c f136c273 nt!IovSpecialIrpCallDriver+0xcd
> b8 eb4368f4 805261cf SYMEVENT!SYMEvent_GetVMDataPtr+0x6ad3
> 1c eb436910 f0dffbfc nt!IovCallDriver+0x31
> 1c eb43692c f0e04d47 filespy!SpyPassThrough_EZ_Create+0x102
> [c:\kernelcode\kernelworkspace\filter\filespy.c @ 2595]
> 90 eb4369bc 805269c4 filespy!SpyCreate+0x597
> [c:\kernelcode\kernelworkspace\filter\filespy.c @ 5329]
> 4c eb436a08 804bda04 nt!IovSpecialIrpCallDriver+0xcd
> 190 eb436b98 8044f5b5 nt!IopParseDevice+0xab4
> 78 eb436c10 804d378b nt!ObpLookupObjectName+0x4e7
> 110 eb436d20 8049dd31 nt!ObOpenObjectByName+0xc5
> dc eb436dfc 8049d8d6 nt!IopCreateFile+0x407
> 48 eb436e44 804a5264 nt!IoCreateFile+0x36
> 40 eb436e84 80463d94 nt!NtCreateFile+0x2e
> 0 eb436e84 8042e953 nt!KiSystemService+0xc4
> a4 eb436f28 f0e088e2 nt!ZwCreateFile+0xb
> 190 eb4370b8 805269c4 filespy!SpyWrite+0x1ab6
> [c:\kernelcode\kernelworkspace\filter\filespy.c @ 11729]
> 4c eb437104 804aca56 nt!IovSpecialIrpCallDriver+0xcd
> 14 eb437118 804a9b99 nt!IopSynchronousServiceTail+0x60
> e8 eb437200 80463d94 nt!NtWriteFile+0x657
> 0 eb437200 8042f613 nt!KiSystemService+0xc4
> 9c eb43729c 8052071f nt!ZwWriteFile+0xb
> a50 eb437cec 8051da22 nt!CmpFileWrite+0x14d
> 58 eb437d44 8051d6f6 nt!HvpWriteLog+0x90
> 10 eb437d54 80518036 nt!HvSyncHive+0x38
> 1c eb437d70 80516dfc nt!CmpDoFlushAll+0x4c
> 8 eb437d78 804168ce nt!CmpLazyFlushWorker+0x16
> 30 eb437da8 80453844 nt!ExpWorkerThread+0xae
> 34 eb437ddc 80468022 nt!PspSystemThreadStartup+0x54
> 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> Regards
> Anurag
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Tony Mason [mailto:xxxxx@osr.com]
> Sent: Friday, January 14, 2005 10:24 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)
>
>
> The mere fact you are USING the TSS is strongly suggestive of the
> double fault case - I’ve never seen any other use of the TSS in
> Windows (that doesn’t mean there isn’t one, but I’ve looked
at the IDT
> enough to know
> that there aren’t a plethora of TSS selectors in there).
>
> TSS is a hardware (x86) context switching mechanism. One of the
> reasons it is employed on the x86 Windows platforms is that it
> switches to a new
> stack. Each processor has a “double fault” stack that is
> used precisely
> in the case where a double fault occurs - because this
> normally happens
> when the stack itself is bad/corrupted/invalid. The TSS
> (selector) then
> forces a hardware context switch to the “new context”. The
> OLD context
> is saved away and processing continues using the NEW context.
>
> The “.tss 28” command says “use the TSS selector at 0x28” and it
> displays the information that was stored there (the state of the
> machine prior to the switch).
>
> By the way: the double fault switch is ALWAYS one-way. The
OS doesn’t
> come back from this switch. So no matter the cause of the
switch, it
> is terminal.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Looking forward to seeing you at the Next OSR File Systems
Class April
> 4, 2004 in Boston!
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
> Sent: Friday, January 14, 2005 10:52 AM
> To: ntdev redirect
> Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)
>
> Just for knowledge :- Could you tell me which part of .tss output
> tells us that it’s a double fault case… And why ??
>
> Also which command will give me amount of stack consumed
per function?
>
> Thanks & Regards
> Anurag
>
> -----Original Message-----
> From: Calvin Guan [mailto:xxxxx@ati.com]
> Sent: Friday, January 14, 2005 8:53 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)
>
>
>
> >kd> .tss 28
> >eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
> edi=00000000
> >eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up
> di ng nz na
> po
> nc
> >cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00210086
> >nt!KiDispatchException+0x25:
> >8042dbbf 53 push ebx
>
> This is a typical double fault caused by stack overflow.
>
> Check if there’s endless recursion call in the call stack
or see which
> function consumed abnormal amount of stack. !analyze -v is
your first
> step to triage.
>
>
> -
> Calvin Guan Software Engineer
> ATI Technologies Inc. www.ati.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
xxxxx@divassoftware.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument:
> ‘’ To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument:
> ‘’ To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

> Now I have the possibilities

1>A recursion
2>abnormal sum of Memory on stack

I am trying to figure out where is code going on recursion.

For the second possibility I would like to know How much of memory is
abnormal memory for the stack ?
I have big chunks like 3bc , 248, 210 , 37c etc…

Kernel stacks are tiny. What, 8K, 12K, something like that? (I’ve
forgotten.) Not big at all. You *really don’t* want to be allocating more
than a few hundred bytes at most in any given stack frame. Anything bigger
pretty much has to go into the heap.

A side effect of the small size is that you don’t want really long call
chains on the stack. Get enough calls on the stack and even at an average
of maybe 24 bytes per frame and you are going to blow stack. A typically
very long call chain might go 20 calls deep or so, if that. Most call
chains are far shorter.

Just glancing at your call chain below, it goes from 5000 to nearly 8000
hex, or 0x3000 bytes long. That is 12K bytes, and is probably pushing the
stack limit if it is 12K, or well over if it is 8K.

So the first thing I can say is this particular call chain uses an unsafe
amount of stack. That by implication is also an abnormal amount of stack.
:slight_smile: The second thing I can say about this call chain is that it is
unusually long.

Now, is it also recursive? Possibly. As others have mentioned, filespy
appears several times on the stack. However, recursion is not necessarily
evil, although it is generally a really bad idea in kernel code. The trick
is it needs to be a short recusrion that only goes down a few levels
(guaranteed!). And it can’t be calling a bunch of other functions in each
of those recursions.

In this particular case recursion was quite possibly evil, since we don’t
know if the machine died during the final recursion, or if it might have
continued foirever. The recursion (if that is what it is) also bringa a lot
of other functions along on each recursion, which is bad.

A typical amount of stack to use might be from the bottom of the stack trace
below up to the first occurance of a filespy reference. Above that starts
to get into the region of improbable.

Loren

Like I have kf output as follows.

kd> kf 50
Memory ChildEBP RetAddr
00000000 8042d3c5 nt!KiTrap08+0x3e
eb43502c eb43502c 8042dc13 nt!KeContextFromKframes+0x9
3bc eb4353e8 80464891 nt!KiDispatchException+0x79
68 eb435450 80464e7b nt!CommonDispatchException+0x4d
0 eb435450 8045a9f8 nt!KiTrap03+0x97
80 eb4354d0 8045a9c1 nt!DebugService+0x10
10 eb4354e0 80454388 nt!DebugPrint+0xd
248 eb435728 eb5387ef nt!DbgPrint+0xac
WARNING: Stack unwind information not available. Following frames may be
wrong.
210 eb435938 f0e02e7e Dbgv+0x7ef
c eb435944 80526626 filespy!Completion_EZ_SetInfo+0x3f
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 4444]
48 eb43598c bfeee818 nt!IovSpecialIrpCompleteRequest+0x18c
c eb435998 bfeef6bd Ntfs!NtfsCompleteRequest+0x5c
37c eb435d14 bfeee3e8 Ntfs!NtfsCommonWrite+0x2b02
68 eb435d7c 805269c4 Ntfs!NtfsFsdWrite+0xee
4c eb435dc8 f136c184 nt!IovSpecialIrpCallDriver+0xcd
b0 eb435e78 805261cf SYMEVENT!SYMEvent_GetVMDataPtr+0x69e4
1c eb435e94 f0dffa0c nt!IovCallDriver+0x31
1c eb435eb0 f0e0864e filespy!SpyPassThrough_EZ_Write+0x102
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 2547]
16c eb43601c 805269c4 filespy!SpyWrite+0x1822
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 11623]
4c eb436068 8041ea32 nt!IovSpecialIrpCallDriver+0xcd
14 eb43607c 8043c9fe nt!IoSynchronousPageWrite+0xa6
d0 eb43614c 8043c50b nt!MiFlushSectionInternal+0x392
40 eb43618c 8040ea6e nt!MmFlushSection+0x1c9
dc eb436268 bff17334 nt!CcFlushCache+0x3f4
10c eb436374 bff17609 Ntfs!LfsFlushLfcb+0x3d4
24 eb436398 bff167cb Ntfs!LfsFlushLbcb+0x9e
28 eb4363c0 bff166e2 Ntfs!LfsFlushToLsnPriv+0xf7
4c eb43640c bff21d12 Ntfs!LfsFlushToLsn+0xb2
34 eb436440 bfeefe0c Ntfs!NtfsCommitCurrentTransaction+0x1ec
10 eb436450 bff0f3ee Ntfs!NtfsCompleteRequest+0x1a
2ec eb43673c bff0c5a2 Ntfs!NtfsCommonCreate+0xe82
b4 eb4367f0 805269c4 Ntfs!NtfsFsdCreate+0x1fe
4c eb43683c f136c273 nt!IovSpecialIrpCallDriver+0xcd
b8 eb4368f4 805261cf SYMEVENT!SYMEvent_GetVMDataPtr+0x6ad3
1c eb436910 f0dffbfc nt!IovCallDriver+0x31
1c eb43692c f0e04d47 filespy!SpyPassThrough_EZ_Create+0x102
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 2595]
90 eb4369bc 805269c4 filespy!SpyCreate+0x597
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 5329]
4c eb436a08 804bda04 nt!IovSpecialIrpCallDriver+0xcd
190 eb436b98 8044f5b5 nt!IopParseDevice+0xab4
78 eb436c10 804d378b nt!ObpLookupObjectName+0x4e7
110 eb436d20 8049dd31 nt!ObOpenObjectByName+0xc5
dc eb436dfc 8049d8d6 nt!IopCreateFile+0x407
48 eb436e44 804a5264 nt!IoCreateFile+0x36
40 eb436e84 80463d94 nt!NtCreateFile+0x2e
0 eb436e84 8042e953 nt!KiSystemService+0xc4
a4 eb436f28 f0e088e2 nt!ZwCreateFile+0xb
190 eb4370b8 805269c4 filespy!SpyWrite+0x1ab6
[c:\kernelcode\kernelworkspace\filter\filespy.c @ 11729]
4c eb437104 804aca56 nt!IovSpecialIrpCallDriver+0xcd
14 eb437118 804a9b99 nt!IopSynchronousServiceTail+0x60
e8 eb437200 80463d94 nt!NtWriteFile+0x657
0 eb437200 8042f613 nt!KiSystemService+0xc4
9c eb43729c 8052071f nt!ZwWriteFile+0xb
a50 eb437cec 8051da22 nt!CmpFileWrite+0x14d
58 eb437d44 8051d6f6 nt!HvpWriteLog+0x90
10 eb437d54 80518036 nt!HvSyncHive+0x38
1c eb437d70 80516dfc nt!CmpDoFlushAll+0x4c
8 eb437d78 804168ce nt!CmpLazyFlushWorker+0x16
30 eb437da8 80453844 nt!ExpWorkerThread+0xae
34 eb437ddc 80468022 nt!PspSystemThreadStartup+0x54
00000000 00000000 nt!KiThreadStartup+0x16

Regards
Anurag

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Friday, January 14, 2005 10:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

The mere fact you are USING the TSS is strongly suggestive of the double
fault case - I’ve never seen any other use of the TSS in Windows (that
doesn’t mean there isn’t one, but I’ve looked at the IDT enough to know
that there aren’t a plethora of TSS selectors in there).

TSS is a hardware (x86) context switching mechanism. One of the reasons
it is employed on the x86 Windows platforms is that it switches to a new
stack. Each processor has a “double fault” stack that is used precisely
in the case where a double fault occurs - because this normally happens
when the stack itself is bad/corrupted/invalid. The TSS (selector) then
forces a hardware context switch to the “new context”. The OLD context
is saved away and processing continues using the NEW context.

The “.tss 28” command says “use the TSS selector at 0x28” and it
displays the information that was stored there (the state of the machine
prior to the switch).

By the way: the double fault switch is ALWAYS one-way. The OS doesn’t
come back from this switch. So no matter the cause of the switch, it is
terminal.

Regards,

Tony

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

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Friday, January 14, 2005 10:52 AM
To: ntdev redirect
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

Just for knowledge :- Could you tell me which part of .tss output tells
us that it’s a double fault case… And why ??

Also which command will give me amount of stack consumed per function?

Thanks & Regards
Anurag

-----Original Message-----
From: Calvin Guan [mailto:xxxxx@ati.com]
Sent: Friday, January 14, 2005 8:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP (7f)

>kd> .tss 28
>eax=eb435644 ebx=eb435344 ecx=eb435330 edx=00000001 esi=eb43542c
edi=00000000
>eip=8042dbbf esp=eb434f78 ebp=eb435314 iopl=0 nv up di ng nz na
po
nc
>cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00210086
>nt!KiDispatchException+0x25:
>8042dbbf 53 push ebx

This is a typical double fault caused by stack overflow.

Check if there’s endless recursion call in the call stack or see which
function consumed abnormal amount of stack. !analyze -v is your first
step to triage.

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

If you’re running out of stack space or otherwise can’t use your current
thread context to do what you need, a good trick is to punt off to a work
item. Set up a work item with IoAllocateWorkItem or suchlike and queue it
with parameters indicating how to pick up where your current thread left
off. If you’re at IRQL < DISPATCH_LEVEL, you can set up an event and wait
until your work item is finished, and this more or less amounts to a
manually initiated context switch to a free worker thread with plenty of
stack to do your bidding.

–Micah Brodsky

“Anurag Sarin” wrote in message
news:xxxxx@ntdev…
Mark,

I suppose “Calling createfile inline in the write path is probably not a
good idea” because of Re-entrancy reasons , hence giving recursion. Am I
right ?

So what can be an alternative for ZwCreateFile and ZwWriteFile to be
called in Write dispatch routine ?

Also for knowledge : from the stack trace below , how to find out that I
am in 4 Stage of recursion. As there are FileSpy functions but are
different function , how to know that the same function is been called 4
times… ???

Thanks
Anurag