Hi,
In your post you seemed to be suggesting that your dispatch entry point
was being called at CLOCK2_LEVEL, but I just wanted to point out that it was
probably not and the reason that you were at CLOCK2 at the point of the
crash was because of the call to KeXxxRaiseToSynch later in the stack (in
fact, if you hadn’t been at PASSIVE or APC your PAGED_CODE() macro would
have asserted.) The fact that it’s an MP system may have something to do
with it, but the real problem here is a NULL pointer derference. The system
is trying to compare word bytes at offset 0x16 from base address 0x0 with
the value 0x1, which isn’t going to fly:
eax=00000000
nt!KiWaitTest+0x31:
804fceb3 6683781601 cmp word ptr [eax+0x16],0x1
ds:0023:00000016=???
Looking at the disassembly of nt!KeSetEvent -> nt!KiWaitTest+0x31, my
guess would be that KiWaitTest is looking at the USHORT WaitType member of a
KWAIT_BLOCK that it got through the KEVENT:
0: kd> dt nt!_KEVENT -r1
+0x000 Header :
+0x000 Type : UChar
+0x001 Absolute : UChar
+0x002 Size : UChar
+0x003 Inserted : UChar
+0x004 SignalState : Int4B
+0x008 WaitListHead : _LIST_ENTRY (A list of KWAIT_BLOCKs of
threads waiting on this object)
0: kd> dt nt!_KWAIT_BLOCK
+0x000 WaitListEntry : _LIST_ENTRY
+0x008 Thread : Ptr32 _KTHREAD
+0x00c Object : Ptr32 Void
+0x010 NextWaitBlock : Ptr32 _KWAIT_BLOCK (Other objects this thread
is waiting on)
+0x014 WaitKey : Uint2B
+0x016 WaitType : Uint2B
If at some point during walking the KWAIT_BLOCKs the system ended up
with a NULL pointer, when KiWaitTest attempted to check the WaitType it
would dereference address NULL+0x16 and bugcheck.
So the course of action would be to
A) Make sure that I’m correct in my analysis - I did this sort of ad hoc
so I might have lost track of a something someplace
B) If that is correct, figure out what exactly is trashed and where it
came from. If this is reproducible, then you should be able to find the
point at which it becomes poison and begin pointing fingers at people (or
begin figuring out a workaround).
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Jorge Lodos” wrote in message news:xxxxx@ntfsd…
> Hi
> Thank you for your help.
> This was a single processor computer, but it is a P4 with hyper-threading,
> so Windows XP treats it like a dual processor. Somehow I didn’t take this
> into consideration, and the problem could be related to NAV performing
> context switching in a MP environment. Indeed, I could not reproduce a
> problem in an older P4.
> Below I include the !thread output, the stack doesn’t seem to be the
> problem.
> I will compare traces from this dump and a running UP system. I’m almost
> certain this is a NAV problem, but still need a workaround 
>
> Best regards
> Jorge
>
>
> 0: kd> !thread
> THREAD 823cbda8 Cid 0004.0010 Teb: 00000000 Win32Thread: 00000000
RUNNING
> on processor 0
> Not impersonating
> DeviceMap e10027b8
> Owning Process 823cc800
> Wait Start TickCount 10708 Elapsed Ticks: 0
> Context Switch Count 1310
> UserTime 00:00:00.0000
> KernelTime 00:00:00.0046
> Start Address nt!ExpWorkerThread (0x80528458)
> Stack Init f8971000 Current f8970d20 Base f8971000 Limit f896e000 Call 0
> Priority 13 BasePriority 13 PriorityDecrement 0 DecrementCount 16
> ChildEBP RetAddr Args to Child
> f8970998 805334b1 0000000a 00000016 0000001c nt!KeBugCheckEx+0x19 (FPO:
> [Non-Fpo])
> f8970998 804fceb3 0000000a 00000016 0000001c nt!KiTrap0E+0x2b5 (FPO: [0,0]
> TrapFrame @ f89709b4)
> f8970a44 804f575e 81f12dd8 823b5ad0 000003e8 nt!KiWaitTest+0x31 (FPO:
> [Non-Fpo])
> f8970a54 f83f3886 823b5b98 00000000 00000000 nt!KeSetEvent+0x58 (FPO:
> [3,0,3])
> f8970a7c f8436365 00f12dd8 82390c50 82390c50 Ntfs!NtfsAddToWorkque+0xf8
> (FPO: [Non-Fpo])
> f8970a8c 804e8a48 81f12dd8 82390c50 e2360398 Ntfs!NtfsOplockComplete+0x4d
> (FPO: [2,0,2])
> f8970aa4 804e8dd6 e2a2f938 81ec8fb4 81ec8d70
> nt!FsRtlRemoveAndCompleteWaitIrp+0x4a (FPO: [1,0,3])
> f8970af0 805537e1 e2360398 81ec8fb4 81ec8d70
> nt!FsRtlAcknowledgeOplockBreak+0x12c (FPO: [Non-Fpo])
> f8970b14 f842ca26 e2511208 81ec8d70 00000000 nt!FsRtlOplockFsctrl+0x8d
(FPO:
> [Non-Fpo])
> f8970b64 f842c963 81efe008 81ec8d70 f8970bb8 Ntfs!NtfsOplockRequest+0xf2
> (FPO: [Non-Fpo])
> f8970b78 f8416a93 81efe008 81ec8d70 f8970bb8 Ntfs!NtfsUserFsRequest+0x112
> (FPO: [Non-Fpo])
> f8970b88 f8416a5b 81efe008 81ec8d70 804ec082
> Ntfs!NtfsCommonFileSystemControl+0x43 (FPO: [2,0,1])
> f8970bfc 804eb3c1 82361770 81ec8d70 823610d8
> Ntfs!NtfsFsdFileSystemControl+0x116 (FPO: [Non-Fpo])
> f8970c0c f848f903 8238c3f0 00000000 f8970c3c nt!IopfCallDriver+0x31 (FPO:
> [0,0,1])
> f8970c1c 804eb3c1 823610d8 81ec8d70 82320b30 sr!SrFsControl+0x11f (FPO:
> [Non-Fpo])
> f8970c2c f8390cdb ffffffff 823203f0 f8970c58 nt!IopfCallDriver+0x31 (FPO:
> [0,0,1])
> f8970c3c f838f39b 81ec8d70 00000000 63f31400
> SAVF!KFSFAttachedDevice::ControlUserFSRequest+0x8b (FPO: [Non-Fpo]) (CONV:
> thiscall) [c:\documents and
> settings\jorgito\desktop\savf\sys\fsflib\fsfattacheddevice.cpp @ 1188]
> f8970c58 f83822ef 81ec8d70 0000000d 823203f0
> SAVF!KFSFAttachedDevice::FileSystemControl+0xbb (FPO: [Non-Fpo]) (CONV:
> thiscall) [c:\savf\sys\fsflib\fsfattacheddevice.cpp @ 568]
> f8970c70 f8381091 81ec8d70 0000000d 823203f0
> SAVF!KFSFAttachedDevice::DeviceIrpDispatch+0x2f (FPO: [Non-Fpo]) (CONV:
> thiscall) [c:\savf\sys\fsflib\fsfattacheddevice.cpp @ 61]
> f8970c88 f83821b6 81ec8d70 8201e002 f8970cf4
> SAVF!SAVFDevice::DeviceIrpDispatch+0x71 (FPO: [Non-Fpo]) (CONV: thiscall)
> [c:\savf\sys\savfdevice.cpp @ 56]
> f8970c9c 804eb3c1 82320338 81ec8d70 f8970cf4
> SAVF!KDriver::DriverIrpDispatch+0x26 (FPO: [Non-Fpo]) (CONV: stdcall)
> [c:\savf\sys\fsflib\driver.cpp @ 381]
> f8970cac eeaaf264 00000000 f8970cf4 82128a08 nt!IopfCallDriver+0x31 (FPO:
> [0,0,1])
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> f8970cc0 eeab444c 82320338 ef400008 f8970cf4 SYMEVENT+0x6264
> f8970c00 82361770 81ec8d70 823610d8 f848f903
> SYMEVENT!EventObjectCreate+0x44c
> f8970c00 82361770 81ec8d70 823610d8 f848f903 0x82361770
> 804eb3c1 54278025 244c8b80 29f98304 03b80772 0x82361770
> ffccc35e 00000000 00000000 00000000 00000000 0x54278025
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
> Sent: Monday, May 24, 2004 6:13 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Problem with NAV
>
> > // The bugcheck occurs here, whith IRQL = CLOCK2_LEVEL, way higher than
> > expected PASSIVE_LEVEL
>
> Is this a multiproc? If so, if you step into KeSetEvent a bit it makes
> sense that you’d be at CLOCK2_LEVEL at this point:
>
>
> nt!KeSetEvent:
> 804ff706 53 push ebx
> 804ff707 56 push esi
> 804ff708 57 push edi
> 804ff709 33c9 xor ecx,ecx
> 804ff70b ff1588f04d80 call dword ptr
> [nt!_imp_KeAcquireQueuedSpinLockRaiseToSynch (804df088)]
>
> And from the DDK:
>
> #define CLOCK2_LEVEL 28 // Interval clock 2 level
> #define IPI_LEVEL 29 // Interprocessor interrupt level
>
>
> #if defined(NT_UP)
> #define SYNCH_LEVEL DISPATCH_LEVEL // synchronization level - UP system
> #else
> #define SYNCH_LEVEL (IPI_LEVEL-1) // synchronization level - MP system
> #endif
>
>
> My guess is that the event getting passed to KeSetEvent is trashed
> somehow. As Dejan pointed out, a stack overflow is entirely possible.
>
> If you do a !thread it’ll give you the current stack pointer and also
> the stack limit, which should tell you pretty quickly if it’s an overflow.
>
> Regards,
>
> -scott
>
>
> –
> Scott Noone
> Software Engineer
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
>
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
> > Sent: Monday, May 24, 2004 4:32 PM
> > To: Windows File Systems Devs Interest List
> > Subject: Re: [ntfsd] Problem with NAV
> >
> >
> > Check locals during the last call inside your driver. See what
items,
> if
> > any,
> > refer to 0x16. Since this is IRP_MN_USER_REQUEST, what type of
processing
> do
> > you do?
> > None? have you checked for stack overflow (you have 5 nested calls
> just
> > of your
> > driver, which will use a lot of stack space).
> >
> > Jorge Lodos wrote:
> >
> > > I just noticed that the original question was missing from my last
> > message, so I
> > > include it again, this time with symbols. For completion, the bugcheck
> > takes place
> > > with or without driver verifier.
> > > SAVF!KFSFAttachedDevice::ControlUserFSRequest+0x8b
> > > [c:\savf\sys\fsflib\fsfattacheddevice.cpp @ 1188]
> > > f8970c58 f83822ef 81ec8d70 0000000d 823203f0
> > > SAVF!KFSFAttachedDevice::FileSystemControl+0xbb
> > > [c:\savf\sys\fsflib\fsfattacheddevice.cpp @ 568]
> > > f8970c70 f8381091 81ec8d70 0000000d 823203f0
> > > SAVF!KFSFAttachedDevice::DeviceIrpDispatch+0x2f
> > > [c:\savf\sys\fsflib\fsfattacheddevice.cpp @ 61]
> > > f8970c88 f83821b6 81ec8d70 8201e002 f8970cf4
> > > SAVF!SAVFDevice::DeviceIrpDispatch+0x71 [c:\savf\sys\savfdevice.cpp @
> 56]
> > > f8970c9c 804eb3c1 82320338 81ec8d70 f8970cf4
> > > SAVF!KDriver::DriverIrpDispatch+0x26 [c:\savf\sys\fsflib\driver.cpp @
> 381]
> >
> > –
> > Kind regards, Dejan M. MVP for DDK
> > http://www.alfasp.com E-mail: xxxxx@alfasp.com
> > Alfa Transparent File Encryptor - Transparent file encryption services.
> > Alfa File Protector - File protection and hiding library for Win32
> > developers.
> > Alfa File Monitor - File monitoring library for Win32 developers.
> >
> >
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: xxxxx@segurmatica.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@segurmatica.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
