> Now I have the possibilities
1>A recursion
2>abnormal sum of Memory on stackI 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.
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+0x16Regards
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.comLooking 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 ebxThis 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=256You 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=256You 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=256You 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=256You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com