Now I don’t know what issue you were addressing. For your own structures the
internal tag does not have to correspond to the allocation tag, although it
is nice if it does. As far as unique allocation tags, I use them all the
time. One tag for all my objects, for a sufficiently complex driver, is too
broad a brush to find leaks quickly. Microsoft ought to consider increasing
the size of the tag value if there is a uniqueness shortage.
=====================
Mark Roddy
-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Wednesday, October 20, 2004 1:05 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP
No - use your own tag for your own data structures. You can’t modify the
system structures. You can of course wrap system structures in a container
of your own, but that would be a desperate move.
=====================
Mark Roddy
-----Original Message-----
From: Mats PETERSSON [mailto:xxxxx@3dlabs.com]
Sent: Wednesday, October 20, 2004 12:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP
So, are you suggesting we add our own tag, something like:
struct Somethign
{
ULONG tag;
…
};
or that we go modify the tag that Windows gave us? That could really hurt if
the guys at MS decided to change the structure (of course, it would be
almost immediately obvious, but still annoyingly unfuture-proof).
–
Mats
xxxxx@lists.osr.com wrote on 10/20/2004 05:33:39 PM:
A simple but effective method is to use data structure tags with known
values. Your object constructer initializes the tag field to its valid
state
and your object destructor resets it to an invalid state. Both valid
and invalid are well defined (e.g. valid==‘FOOB’ and invalid==‘foob’.)
You
can
now assert valid and invalid appropriately and detect many stale
pointers,
bogus pointers, ‘re-frees’ etc. close to the point of occurrence.
As mentioned elsewhere, unique allocation tag values for each object
type help to isolate both leaks and corruption. The tag value is back
a few
bytes
from the address returned from ExAllocate*.
=====================
Mark Roddy
-----Original Message-----
From: Mats PETERSSON [mailto:xxxxx@3dlabs.com]
Sent: Wednesday, October 20, 2004 10:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP
Thanks for the Thanks.
I’d say that this is why we should ALL run with DV on at ALL times
(except
perhaps when performance testing ;-).
Another thing to help this scenario is to wrap the ExAllocatePoolXXXX
and ExFreePoolXXXX with some wrapper functions that track allocations
(and
thus
know that this allocation has already been freed).
There are several other benefits with this “wrapping” method. For
example you can track memory leaks, check for overflows (by allocating
extra
bytes
at the beginning and end of the buffer).
For large projects, this is definitely worth doing. For small projects
where
you can easily track things by hand, Driver Verifier is probably
sufficient
for seeing double frees, buffer overwriting, etc.
–
Mats
xxxxx@lists.osr.com wrote on 10/20/2004 03:29:03 PM:
>
> Well I agree with you completely Mr. Mechanic :).
>
> I did find my problem. I guess your 3rd scenario fits the cause.
> It was this, that I tried to access a freed memory location more
> than once .
> ----------------------------------------
> if ( PFileDC->Buffer != NULL )
> {
> DbgPrint(“\nWR:Freeing Memory PFileDC”);
> ExFreePoolWithTag(PFileDC->Buffer,‘pmoC’);
> PFileDC->Buffer=NULL; //???Boom !If above line has
> ExFreePoolWithTag(PFileDC,‘pmoC’);
> PFileDC->MaximumLength=0; //Access violation
> PFileDC->Length=0; // Access violation
> ExFreePoolWithTag(PFileDC,‘pmoC’);
> PFileDC=NULL;
> }
> -----------------------------------------------
>
> Well I got to know this only when I switched back to Driver Verifier
> as it bug checked fro double freeing.
> Looking through just you code and trying to figure out what’s wrong
> is a crazy making task.
>
> I guess other starters will benefit from this post as one of the
> possible reasons for this bug.
>
> Thanks so much Mats , Dev and Roddy for your inputs.
>
> Anurag
>
>
>
> -----Original Message-----
> From: Mats PETERSSON [mailto:xxxxx@3dlabs.com]
> Sent: Monday, October 18, 2004 7:43 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP
>
>
>
>
>
>
>
> So, we have this scenario. You’ve called a mechanic out, because
> your car doesn’t start. Now you ask the mechanic (when he arrives)
> what you should do to avoid it. Unless the mechanic knows what’s
> wrong with your car, he can’t really tell you how to avoid the
situation, right?
>
> In this case, you need to first figure out WHY it’s running out of
> stack space. Then fix the problem. There are a couple of common
scenarios:
1.
> You’ve got some form of recursion going on (say, a filter driver
> that calls the real driver that then calls the same filter driver
> for some reason, etc, etc), 2. You put too many/large variables on
> the stack in some function, and thus overflows the stack. 3.
> Something is scribbling on top of something that it shouldn,t and
> thus the saved frame pointer is being clobbered with some random
> data and causing a crash (the frame pointer is the pointer back to
> the previous stack-frame, and the frame pointer becomes the stack
> when exiting the
function).
>
> Just like the solution is different if your ignition is broken or
> you filled a petrol car with diesel, the solution to the above types
> of problem is different.
>
> Now, once you’ve figured out wht the problem is, you can PROBABLY
> solve the situation yourself. Should it be that you can not at all
> come up with a solution AFTER you’ve identified the real cause of
> the problem, you may want to ask this forum again, but putting up 15
> hypothetical answers won’t really help you at this point, so let’s
> try to find the RIGHT answer after you’ve identified what YOUR
> problem is,
please…
>
> [The reason I’m almost confident that you can find the solution
> yourself is that most of the time, these traps happen because the
> driver is BROKEN in some sever way, rather than actually running out
> of stack from proper operations].
>
> –
> Mats
>
> xxxxx@lists.osr.com wrote on 10/18/2004 02:55:10 PM:
>
> >
> > Thanks Mats,
> >
> > >>It normally means that the system ran out of stack space
> >
> > So what do I do to get rid of this??
> > -a
> >
> > -----Original Message-----
> > From: Mats PETERSSON [mailto:xxxxx@3dlabs.com]
> > Sent: Monday, October 18, 2004 6:29 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] UNEXPECTED_KERNEL_MODE_TRAP
> >
> >
> >
> >
> >
> >
> >
> > Trap 8 is double fault. It normally means that the system ran out
> > of stack space or clobbered the stack so that it’s no longer able
> > to “trap” (e.g. set EBP = 0, put ebp into esp and try to return
> > from function will do this).
> >
> > –
> > Mats
> >
> > xxxxx@lists.osr.com wrote on 10/18/2004 01:52:39 PM:
> >
> > > Hello All,
> > >
> > > I got no clue whats wrong??
> > > I am making a files system filter driver , its working with user
> > > mode application and a service??? It tells me about some
> > > hardware fault - I don’t think so. No fixed action which leads this
???
> > > Any ideas???
> > >
> > > -Anurag
> > > ----------------------------------------------------------------
> > > –
> > > –
> > > –
> > > –
> > > UNEXPECTED_KERNEL_MODE_TRAP (7f) This means a trap occurred in
> > > kernel mode, and it’s a trap of a kind that the kernel isn’t
> > > allowed to have/catch (bound trap) or that is always instant
> > > death (double fault). The first number in the bugcheck params
> > > is the number of the trap (8 = double fault,
> > > etc) Consult an Intel x86 family manual to learn more about what
> > > these traps are. Here is a *portion* of those codes:
> > > If kv shows a taskGate
> > > use .tss on the part before the colon, then kv.
> > > Else if kv shows a trapframe
> > > use .trap on that value
> > > Else
> > > .trap on the appropriate frame will show where the trap
> > > was taken
> > > (on x86, this will be the ebp that goes with the
> > > procedure
> > > KiTrap)
> > > Endif
> > > kb will then show the corrected stack.
> > > Arguments:
> > > Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
> > > Arg2: 00000000
> > > Arg3: 00000000
> > > Arg4: 00000000
> > >
> > > Debugging Details:
> > > ------------------
> > >
> > >
> > > BUGCHECK_STR: 0x7f_8
> > >
> > > TSS: 00000028 – (.tss 28)
> > > eax=b7a0c030 ebx=00000020 ecx=b7a0c0b0 edx=00000000 esi=8006a568
> > > edi=00000010
> > > eip=80066a25 esp=b7a0bfe8 ebp=b7a0c028 iopl=0 nv up di ng
nz
> > na
> > > po nc
> > > cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> > > efl=00010086
> > > hal!CpReadLsr+0x6:
> > > 80066a25 56 push esi
> > > Resetting default scope
> > >
> > > DEFAULT_BUCKET_ID: DRIVER_FAULT
> > >
> > > LAST_CONTROL_TRANSFER: from 80066c58 to 80066a25
> > >
> > > STACK_TEXT:
> > > b7a0c028 80066c58 8006a568 00000020 00000003 hal!CpReadLsr+0x6
> > > b7a0c03c 80068d34 8006a568 00000030 80538191 hal!CpPutByte+0x50
> > > b7a0c048 80538191 00000030 b7a0c0b0 0000002b
> > > hal!KdPortPutByte+0xe b7a0c05c 805384bf b7a0c078 00000030
> > > 80000003 nt!KdpSendString+0x1e
> > > b7a0c088 80539496 00000003 b7a0c0b0 b7a0c0b8
> > > nt!KdpSendPacket+0x96 b7a0c0c0 8053931e b7a0c13c b7a0c55c
> > > b7a0c5b0
> > > nt!KdpPrintString+0x72
> > > b7a0c178 80430867 b7a0c5b0 00000000 b7a0c55c nt!KdpTrap+0x2e1
> > > b7a0c540
> >
> > > 8046651b b7a0c55c 00000000 b7a0c5b0 nt!KiDispatchException+0xaf
> > > b7a0c5a8 80466af5 80066a35 000003fd b7a0c840
> > > nt!CommonDispatchException+0x4d b7a0c5a8 8045cd10 80066a35
> > > 000003fd b7a0c840 nt!KiTrap03+0x97 b7a0c628 8045ccd9 00000001
> > > b7a0c658 00000000
> >
> > > nt!DebugService+0x10 b7a0c638 80456545 b7a0c658 8137119b
> > > 81371008 nt!DebugPrint+0xd b7a0c880 ed59c7cc b7a0c88c 4349440a
> > > 6c61433a nt!DbgPrint+0xac
> > > WARNING: Stack unwind information not available. Following
> > > frames may be wrong. b7a0ca8c b6eaf67c b6eaeac8 81371008
> > > 8137119b
> > > Dbgv+0x7cc b7a0cbc4 8041fd3f 814c3380 81371008 00000000
> > > SysOn!Completion_EZ+0xb2d
> > > [c:\kernelcode\kernelworkspace\filter\filespy.c @ 3180] b7a0cbf0
> > > bfeee818 00000000 8186d648 bfeef6bd
> > nt!IopfCompleteRequest+0xab
> > > b7a0cbfc bfeef6bd 814eb408 81371008 00000000
> > > Ntfs!NtfsCompleteRequest+0x5c b7a0cf78 bfeee3e8 814eb408
> > > 81371008 8186e760
> > Ntfs!NtfsCommonWrite+0x2b02
> > > b7a0cfe0 8041fb8b 8186e760 81371008 80421237
> > > Ntfs!NtfsFsdWrite+0xee
> > > b7a0cff4 b7210184 00000000 b7a0d03c 81553848
> > > nt!IopfCallDriver+0x35
> > > b7a0d088 b6eb440e 814c3380 81371008 814c3380
> > > SYMEVENT!SYMEvent_GetVMDataPtr+0x69e4
> > > b7a0d1f4 8041fb8b 814c3380 81371008 8186d538
> > > SysOn!SpyWrite+0x160a
> > > [c:\kernelcode\kernelworkspace\filter\filespy.c @ 9276] b7a0d208
> > > 804214cc b7a0d244 b7a0d260 8186d348 nt!IopfCallDriver+0x35
> > > b7a0d21c
> > > 8043de68 8186d538 b7a0d244 b7a0d2cc
> > > nt!IoSynchronousPageWrite+0xa6
> > > b7a0d2e8 8043da84 e134a00c e134a010 00000019
> > > nt!MiFlushSectionInternal+0x36a
> > > b7a0d328 804110f4 8186d380 00000003 00001000
> > > nt!MmFlushSection+0x1cb b7a0d400 bff17334 8186d614 b7a0d49c
> > > 00001000 nt!CcFlushCache+0x3c2 b7a0d50c bff17609 e1347648
> > > e13233c8
> > > e1347648 Ntfs!LfsFlushLfcb+0x3d4 b7a0d530 bff167cb e1347648
> > > e13233c8 e1347648 Ntfs!LfsFlushLbcb+0x9e
> > > b7a0d558 bff166e2 e1347648 54853569 00000000
> > Ntfs!LfsFlushToLsnPriv+0xf7
> > > b7a0d5a4 bff21d12 e12e2dc8 54853569 00000000
> > > Ntfs!LfsFlushToLsn+0xb2
>
> > > b7a0d5d8 bfeefe0c 81644de8 00000000 e353da18
> > > Ntfs!NtfsCommitCurrentTransaction+0x1ec
> > > b7a0d5e8 bfeef6bd 81644de8 814d5a28 00000000
> > > Ntfs!NtfsCompleteRequest+0x1a b7a0d964 bfeee3e8 81644de8
> > > 814d5a28 8186e760
> > Ntfs!NtfsCommonWrite+0x2b02
> > > b7a0d9cc 8041fb8b 8186e760 814d5a28 80421237
> > > Ntfs!NtfsFsdWrite+0xee b7a0d9e0 b7210184 00000000 b7a0da28
> > > 81553848 nt!IopfCallDriver+0x35
> > > b7a0da74 b6eb440e 814c3380 814d5a28 814c3380
> > > SYMEVENT!SYMEvent_GetVMDataPtr+0x69e4
> > > b7a0dbe0 8041fb8b 814c3380 814d5a28 814d5a28
> > > SysOn!SpyWrite+0x160a
> > > [c:\kernelcode\kernelworkspace\filter\filespy.c @ 9276] b7a0dbf4
> > > 8049a586 814d5bdc 00000000 814d5a28 nt!IopfCallDriver+0x35
> > > b7a0dc08
> > > 80499b39 814c3380 814d5a28 813c1a48
> > > nt!IopSynchronousServiceTail+0x60 b7a0dce4 80465691 00000274
> > > 00000000 00000000 nt!NtWriteFile+0x67a b7a0dce4 80401711
> > > 00000274 00000000 00000000 nt!KiSystemService+0xc4 b7a0dd80
> > > b6ead53f
> > > 00000274
>
> > > 00000000 00000000 nt!ZwWriteFile+0xb b7a0ddfc b6eb99ef b7a0de94
> > > b7a0de6c 814c3380 SysOn!LogModFiles+0x191
> > > [c:\kernelcode\kernelworkspace\filter\filespy.c @ 437] b7a0dfa4
> > > 8041fb8b 814c3380 81468468 8146861c SysOn!SpySetInfo+0x23c2
> > > [c:\kernelcode\kernelworkspace\filter\filespy.c @ 10962]
> > > b7a0dfb8
> > > 80498f77 b7a0e0d4 b7a0e160 80498c08 nt!IopfCallDriver+0x35
> > > b7a0e0b8
> > > 80465691 00000250 b7a0e194 b7a0e16c
> > > nt!NtSetInformationFile+0x58a
> > > b7a0e0b8 80401465 00000250 b7a0e194 b7a0e16c
> > > nt!KiSystemService+0xc4
> > > b7a0e144 b6ff92de 00000250 b7a0e194 b7a0e16c
> > nt!ZwSetInformationFile+0xb
> > > b7a0e19c b6ff9752 00000250 81375e0c 00000001 SAVRT+0x2f2de
> > >
> > >
> > > FOLLOWUP_IP:
> > > Dbgv+7cc
> > > ed59c7cc eb22 jmp Dbgv+0x7f0 (ed59c7f0)
> > >
> > > SYMBOL_STACK_INDEX: d
> > >
> > > 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
> > > ---------
> > >
> > >
> > > —
> > > 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:NT000058A2
> >
> >
> >
> > —
> > 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:NT000058D6
>
>
>
> —
> 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:NT00005C6A
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.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: xxxxx@3dlabs.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT00005CE6
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.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: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
which uses a structure and bugs are catched immediatelly. Unique allocation tags help to find leaks. I usually use two tag chars to identify driver and next two chars are unique per allocation: ‘aAdD’.