Help on a crash dump

Was wondering if anyone could give some pointers to the following stack trace to a crash dump.
The system was loading up a file system filter driver. The crash seems to occur whenever a QueryDirectory call is made.

Thanks,

Will

kv
fffffffff04e6c38 ffffffff804171a0 0000000000000000 0000000000000000 0000000000000000 NTOSKRNL!KiTrap0E+0x27b (FPO: [0,0] TrapFrame @ f04e6c38)
fffffffff04e6cc4 ffffffff804166f4 fffffffff04e7050 fffffffff04e7050 0000000000000000 NTOSKRNL!@ExpFindCurrentThread@8+0x136 (EBP)
fffffffff04e6cdc ffffffff80416620 ffffffff810e6c14 0000000000000001 fffffffff04e7000 NTOSKRNL!ExpAcquireResourceSharedLite+0xd1 (EBP)
fffffffff04e6cec ffffffffbff33cc6 ffffffff810e6c14 0000000000000001 ffffffffac017fdc NTOSKRNL!ExAcquireResourceSharedLite+0x43 (EBP)
fffffffff04e6cfc ffffffffbff3161b fffffffff04e7050 ffffffff810e6810 0000000000000001 NTFS!NtfsCommonCleanup+0xfffffffffffeadf8 (FPO: [3,0,1])
fffffffff04e7000 ffffffffbff43ac3 fffffffff04e7050 ffffffffac017e70 0000000000000000 NTFS!NtfsRemoveCachedLcn+0x14 (EBP)
fffffffff04e717c fffffffff13f9269 ffffffffac017e70 fffffffff04e74d8 ffffffff814a0800 NTFS!NtfsQueryDirectory+0x1031b (EBP)
fffffffff04e7190 ffffffff804e534c ffffffffac017e70 fffffffff04e74d8 ffffffff810e6740 MPMON!0xFFFFFFFFF13F9269 (No FPO)
fffffffff04e7324 ffffffff8044f0f2 ffffffff81484430 0000000000000000 fffffffff04e73d0 NTOSKRNL!IopPnPDispatch+0x48dc6 (EBP)
fffffffff04e7390 ffffffff8049a7fb 0000000000000000 fffffffff04e7400 0000000000000040 NTOSKRNL!ObpLookupObjectName+0x43d (EBP)
fffffffff04e74a0 ffffffff804b6fc9 0000000000000000 0000000000000000 fffffffff04e7501 NTOSKRNL!NtLockVirtualMemory+0xbb (EBP)
fffffffff04e7614 ffffffff80462cf1 0000000000daeda8 0000000000daed80 0000000000000001 NTOSKRNL!@xHalIoAssignDriveLetters@16+0xfffffffffffebf7b (EBP)


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Wil,

What version of the debugger are you using? I haven’t seen recent versions
displaying sign-extended values, so if you aren’t using the current stuff,
you really should upgrade (http://www.microsoft.com/ddk/debugging
http: .)

Use the trap frame information with the “.trap ” command (in this
case 0xf04e6c38) so you can see what actually happened. Also, confirm that
you are using the correct symbols, since the stack trace you sent looks like
garbage to me (it isn’t very likely that IopPnpDispatch would be in the
trace before NtfsQueryDirectory, and it isn’t likely that NtfsCommonCleanup
would EVER be called from NtfsRemoveCachedLcn.) I can certainly believe the
ExAcquireResource* things since they are “standard” stuff, but given the
rest of what looks dubious, I wouldn’t be trying to draw conclusions from
it.

If you can’t make any sense of it, I’ll be happy to look at it - I’m always
looking for interesting dumps to use in my kernel debug lab class.

Regards,

Tony

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

-----Original Message-----
From: william [mailto:xxxxx@javabear.com]
Sent: Friday, November 02, 2001 3:46 PM
To: File Systems Developers
Subject: [ntfsd] Help on a crash dump

Was wondering if anyone could give some pointers to the following stack
trace to a crash dump.
The system was loading up a file system filter driver. The crash seems to
occur whenever a QueryDirectory call is made.

Thanks,

Will

> kv
fffffffff04e6c38 ffffffff804171a0 0000000000000000 0000000000000000
0000000000000000 NTOSKRNL!KiTrap0E+0x27b (FPO: [0,0] TrapFrame @ f04e6c38)
fffffffff04e6cc4 ffffffff804166f4 fffffffff04e7050 fffffffff04e7050
0000000000000000 NTOSKRNL!@ExpFindCurrentThread@8+0x136 (EBP)
fffffffff04e6cdc ffffffff80416620 ffffffff810e6c14 0000000000000001
fffffffff04e7000 NTOSKRNL!ExpAcquireResourceSharedLite+0xd1 (EBP)
fffffffff04e6cec ffffffffbff33cc6 ffffffff810e6c14 0000000000000001
ffffffffac017fdc NTOSKRNL!ExAcquireResourceSharedLite+0x43 (EBP)
fffffffff04e6cfc ffffffffbff3161b fffffffff04e7050 ffffffff810e6810
0000000000000001 NTFS!NtfsCommonCleanup+0xfffffffffffeadf8 (FPO: [3,0,1])
fffffffff04e7000 ffffffffbff43ac3 fffffffff04e7050 ffffffffac017e70
0000000000000000 NTFS!NtfsRemoveCachedLcn+0x14 (EBP)
fffffffff04e717c fffffffff13f9269 ffffffffac017e70 fffffffff04e74d8
ffffffff814a0800 NTFS!NtfsQueryDirectory+0x1031b (EBP)
fffffffff04e7190 ffffffff804e534c ffffffffac017e70 fffffffff04e74d8
ffffffff810e6740 MPMON!0xFFFFFFFFF13F9269 (No FPO)
fffffffff04e7324 ffffffff8044f0f2 ffffffff81484430 0000000000000000
fffffffff04e73d0 NTOSKRNL!IopPnPDispatch+0x48dc6 (EBP)
fffffffff04e7390 ffffffff8049a7fb 0000000000000000 fffffffff04e7400
0000000000000040 NTOSKRNL!ObpLookupObjectName+0x43d (EBP)
fffffffff04e74a0 ffffffff804b6fc9 0000000000000000 0000000000000000
fffffffff04e7501 NTOSKRNL!NtLockVirtualMemory+0xbb (EBP)
fffffffff04e7614 ffffffff80462cf1 0000000000daeda8 0000000000daed80
0000000000000001 NTOSKRNL!@xHalIoAssignDriveLetters@16+0xfffffffffffebf7b
(EBP)

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:>

Hi Tony:

Thanks for the reply. I’m using windbg version 5.00.2195.10. You are
right, it doesn’t look like the symbols match up with the kernel version.
The crash dump occurs consistently on a retail version of Windows 2000. I
have not been able to replicate it on my development machine (which of
course has the debug kernel). I assume that I have to get the retail version
symbols installed in order to do a proper bug trace. I will attempt to do
that and supply you with a more coherent picture.
What I find rather interesting is that the crash dump appears to occur
consistently on machines that have less memory. I have been able to
replicate the crash dump on two machines running the same retail version of
Win2K when they have had 128 megabytes or less RAM. One was a PIII and one
was a PII. I have not, however, been able to replicate the crash dump when
it is running on a machine that has 256 megabytes of RAM or above. I suspect
that it may be paged pool resource problem, but this is mere speculation at
this point.
I’d like to take up your offer and send you the crash dump. Driver
source contributing to the crash can also be made available for educational
purposes. What’s a good way of doing this? Please let me know how to get in
contact with you.

Thanks,

Will

----- Original Message -----
From: “Tony Mason”
To: “File Systems Developers”
Sent: Sunday, November 04, 2001 12:28 PM
Subject: [ntfsd] RE: Help on a crash dump

> Wil,
>
> What version of the debugger are you using? I haven’t seen recent
versions
> displaying sign-extended values, so if you aren’t using the current stuff,
> you really should upgrade (http://www.microsoft.com/ddk/debugging
> http: .)
>
> Use the trap frame information with the “.trap ” command (in this
> case 0xf04e6c38) so you can see what actually happened. Also, confirm
that
> you are using the correct symbols, since the stack trace you sent looks
like
> garbage to me (it isn’t very likely that IopPnpDispatch would be in the
> trace before NtfsQueryDirectory, and it isn’t likely that
NtfsCommonCleanup
> would EVER be called from NtfsRemoveCachedLcn.) I can certainly believe
the
> ExAcquireResource* things since they are “standard” stuff, but given the
> rest of what looks dubious, I wouldn’t be trying to draw conclusions from
> it.
>
> If you can’t make any sense of it, I’ll be happy to look at it - I’m
always
> looking for interesting dumps to use in my kernel debug lab class.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com http:</http:>
>
>
> -----Original Message-----
> From: william [mailto:xxxxx@javabear.com]
> Sent: Friday, November 02, 2001 3:46 PM
> To: File Systems Developers
> Subject: [ntfsd] Help on a crash dump
>
> Was wondering if anyone could give some pointers to the following stack
> trace to a crash dump.
> The system was loading up a file system filter driver. The crash seems to
> occur whenever a QueryDirectory call is made.
>
> Thanks,
>
> Will
>
> > kv
> fffffffff04e6c38 ffffffff804171a0 0000000000000000 0000000000000000
> 0000000000000000 NTOSKRNL!KiTrap0E+0x27b (FPO: [0,0] TrapFrame @ f04e6c38)
> fffffffff04e6cc4 ffffffff804166f4 fffffffff04e7050 fffffffff04e7050
> 0000000000000000 NTOSKRNL!@ExpFindCurrentThread@8+0x136 (EBP)
> fffffffff04e6cdc ffffffff80416620 ffffffff810e6c14 0000000000000001
> fffffffff04e7000 NTOSKRNL!ExpAcquireResourceSharedLite+0xd1 (EBP)
> fffffffff04e6cec ffffffffbff33cc6 ffffffff810e6c14 0000000000000001
> ffffffffac017fdc NTOSKRNL!ExAcquireResourceSharedLite+0x43 (EBP)
> fffffffff04e6cfc ffffffffbff3161b fffffffff04e7050 ffffffff810e6810
> 0000000000000001 NTFS!NtfsCommonCleanup+0xfffffffffffeadf8 (FPO: [3,0,1])
> fffffffff04e7000 ffffffffbff43ac3 fffffffff04e7050 ffffffffac017e70
> 0000000000000000 NTFS!NtfsRemoveCachedLcn+0x14 (EBP)
> fffffffff04e717c fffffffff13f9269 ffffffffac017e70 fffffffff04e74d8
> ffffffff814a0800 NTFS!NtfsQueryDirectory+0x1031b (EBP)
> fffffffff04e7190 ffffffff804e534c ffffffffac017e70 fffffffff04e74d8
> ffffffff810e6740 MPMON!0xFFFFFFFFF13F9269 (No FPO)
> fffffffff04e7324 ffffffff8044f0f2 ffffffff81484430 0000000000000000
> fffffffff04e73d0 NTOSKRNL!IopPnPDispatch+0x48dc6 (EBP)
> fffffffff04e7390 ffffffff8049a7fb 0000000000000000 fffffffff04e7400
> 0000000000000040 NTOSKRNL!ObpLookupObjectName+0x43d (EBP)
> fffffffff04e74a0 ffffffff804b6fc9 0000000000000000 0000000000000000
> fffffffff04e7501 NTOSKRNL!NtLockVirtualMemory+0xbb (EBP)
> fffffffff04e7614 ffffffff80462cf1 0000000000daeda8 0000000000daed80
> 0000000000000001 NTOSKRNL!@xHalIoAssignDriveLetters@16+0xfffffffffffebf7b
> (EBP)
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@javabear.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:>

Tony:

Thanks for the heads up on the debugger. The installed windbg was from
the original Win2K DDK and was pretty ancient.
I’ve installed (hopefully) a more current version and I believe that I’ve
installed the correct symbols. I’ve done another analysis fo the crash dump.
Let me know if this one makes more sense to you (or anyone else who wishes
to comment on this list). The kernel (retail) version being used is: Windows
2000 Kernel Version 2195 (Service Pack 1) UP Free x86 compatible.

Kernel base = 0x80400000 PsLoadedModuleList = 0x8046b618
Use !analyzebugcheck -v to get more information.

BugCheck A, {0, 2, 0, 8041727e}

Probably caused by driver ( +0x50005c )

Followup : MachineOwner

kd> kv

ChildEBP RetAddr Args to Child

f0434ad0 8041727e 80069794 f0434b2c 8052d800 ntoskrnl!KiTrap0E+0x27c (FPO:
[0,0] TrapFrame @ f0434ad0)

f0434b50 8052cd20 b508d800 00000800 b508d800
ntoskrnl!ExpCheckForResource+0x38 (FPO: [Non-Fpo])

f0434b6c 80532855 b508d800 f0434bc4 8053283f
ntoskrnl!ExFreePoolSanityChecks+0x5e (FPO: [EBP 0xb508d800] [1,0,4])

b508d800 0050005c 006f0072 00720067 006d0061
ntoskrnl!VerifierFreePoolWithTag+0x14 (FPO: [Non-Fpo])

00000040 00000000 00000000 00000000 00000000 0x50005c

kd> .trap f0434ad0

eax=804749f0 ebx=00000800 ecx=b508e000 edx=00000000 esi=00000000
edi=b508d800

eip=8041727e esp=f0434b44 ebp=f0434b50 iopl=0 nv up ei pl nz na po cy

vip=0 vif=0

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000307

ErrCode = 00000000

8041727e 8b36 mov esi,[esi]

kd> !analyzebugcheck -v

****************************************************************************
***

* *

* Bugcheck Analysis *

* *

****************************************************************************
***

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pagable (or completely invalid) address at
an

interrupt request level (IRQL) that is too high. This is usually

caused by drivers using improper addresses.

If a kernel debugger is available get the stack backtrace.

Arguments:

Arg1: 00000000, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: 8041727e, address which referenced memory

Details:

Read address 00000000, Unknown

Current IRQL 2

Fault occurred in driver ntoskrnl.exe ( ntoskrnl!ExpCheckForResource+0x38 )

8041727e 8b36 mov esi,[esi]

Probably caused by driver ntoskrnl.exe ( +0x50005c )

Followup : MachineOwner

BUCKET: 0xA_2_ntoskrnl!ExpCheckForResource_ntoskrnl.exe

ChildEBP RetAddr

f0434b50 8052cd20 ntoskrnl!ExpCheckForResource+0x38

f0434b6c 80532855 ntoskrnl!ExFreePoolSanityChecks+0x5e

b508d800 0050005c ntoskrnl!VerifierFreePoolWithTag+0x14

00000040 00000000 0x50005c

Creating .\DMP1F.tmp - mini kernel dump

----- Original Message -----
From: “Tony Mason”
To: “File Systems Developers”
Sent: Sunday, November 04, 2001 12:28 PM
Subject: [ntfsd] RE: Help on a crash dump

> Wil,
>
> What version of the debugger are you using? I haven’t seen recent
versions
> displaying sign-extended values, so if you aren’t using the current stuff,
> you really should upgrade (http://www.microsoft.com/ddk/debugging
> http: .)
>
> Use the trap frame information with the “.trap ” command (in this
> case 0xf04e6c38) so you can see what actually happened. Also, confirm
that
> you are using the correct symbols, since the stack trace you sent looks
like
> garbage to me (it isn’t very likely that IopPnpDispatch would be in the
> trace before NtfsQueryDirectory, and it isn’t likely that
NtfsCommonCleanup
> would EVER be called from NtfsRemoveCachedLcn.) I can certainly believe
the
> ExAcquireResource* things since they are “standard” stuff, but given the
> rest of what looks dubious, I wouldn’t be trying to draw conclusions from
> it.
>
> If you can’t make any sense of it, I’ll be happy to look at it - I’m
always
> looking for interesting dumps to use in my kernel debug lab class.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com http:</http:>
>
>
> -----Original Message-----
> From: william [mailto:xxxxx@javabear.com]
> Sent: Friday, November 02, 2001 3:46 PM
> To: File Systems Developers
> Subject: [ntfsd] Help on a crash dump
>
> Was wondering if anyone could give some pointers to the following stack
> trace to a crash dump.
> The system was loading up a file system filter driver. The crash seems to
> occur whenever a QueryDirectory call is made.
>
> Thanks,
>
> Will
>
> > kv
> fffffffff04e6c38 ffffffff804171a0 0000000000000000 0000000000000000
> 0000000000000000 NTOSKRNL!KiTrap0E+0x27b (FPO: [0,0] TrapFrame @ f04e6c38)
> fffffffff04e6cc4 ffffffff804166f4 fffffffff04e7050 fffffffff04e7050
> 0000000000000000 NTOSKRNL!@ExpFindCurrentThread@8+0x136 (EBP)
> fffffffff04e6cdc ffffffff80416620 ffffffff810e6c14 0000000000000001
> fffffffff04e7000 NTOSKRNL!ExpAcquireResourceSharedLite+0xd1 (EBP)
> fffffffff04e6cec ffffffffbff33cc6 ffffffff810e6c14 0000000000000001
> ffffffffac017fdc NTOSKRNL!ExAcquireResourceSharedLite+0x43 (EBP)
> fffffffff04e6cfc ffffffffbff3161b fffffffff04e7050 ffffffff810e6810
> 0000000000000001 NTFS!NtfsCommonCleanup+0xfffffffffffeadf8 (FPO: [3,0,1])
> fffffffff04e7000 ffffffffbff43ac3 fffffffff04e7050 ffffffffac017e70
> 0000000000000000 NTFS!NtfsRemoveCachedLcn+0x14 (EBP)
> fffffffff04e717c fffffffff13f9269 ffffffffac017e70 fffffffff04e74d8
> ffffffff814a0800 NTFS!NtfsQueryDirectory+0x1031b (EBP)
> fffffffff04e7190 ffffffff804e534c ffffffffac017e70 fffffffff04e74d8
> ffffffff810e6740 MPMON!0xFFFFFFFFF13F9269 (No FPO)
> fffffffff04e7324 ffffffff8044f0f2 ffffffff81484430 0000000000000000
> fffffffff04e73d0 NTOSKRNL!IopPnPDispatch+0x48dc6 (EBP)
> fffffffff04e7390 ffffffff8049a7fb 0000000000000000 fffffffff04e7400
> 0000000000000040 NTOSKRNL!ObpLookupObjectName+0x43d (EBP)
> fffffffff04e74a0 ffffffff804b6fc9 0000000000000000 0000000000000000
> fffffffff04e7501 NTOSKRNL!NtLockVirtualMemory+0xbb (EBP)
> fffffffff04e7614 ffffffff80462cf1 0000000000daeda8 0000000000daed80
> 0000000000000001 NTOSKRNL!@xHalIoAssignDriveLetters@16+0xfffffffffffebf7b
> (EBP)
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@javabear.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:>

Will,

First, upgrade to the current debugger - the version you are using is VERY
obsolete. Also, you don’t need to do anything about the symbols except
point them to the public symbol server.

Both of these are easily found on the Microsoft web site -
http://www.microsoft.com/ddk/debugging.

Regards,

Tony

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

-----Original Message-----
From: william [mailto:xxxxx@javabear.com]
Sent: Wednesday, November 07, 2001 3:54 PM
To: File Systems Developers
Subject: [ntfsd] RE: Help on a crash dump

Hi Tony:

Thanks for the reply. I’m using windbg version 5.00.2195.10. You are
right, it doesn’t look like the symbols match up with the kernel version.
The crash dump occurs consistently on a retail version of Windows 2000. I
have not been able to replicate it on my development machine (which of
course has the debug kernel). I assume that I have to get the retail version
symbols installed in order to do a proper bug trace. I will attempt to do
that and supply you with a more coherent picture.
What I find rather interesting is that the crash dump appears to occur
consistently on machines that have less memory. I have been able to
replicate the crash dump on two machines running the same retail version of
Win2K when they have had 128 megabytes or less RAM. One was a PIII and one
was a PII. I have not, however, been able to replicate the crash dump when
it is running on a machine that has 256 megabytes of RAM or above. I suspect
that it may be paged pool resource problem, but this is mere speculation at
this point.
I’d like to take up your offer and send you the crash dump. Driver
source contributing to the crash can also be made available for educational
purposes. What’s a good way of doing this? Please let me know how to get in
contact with you.

Thanks,

Will

----- Original Message -----
From: “Tony Mason”
To: “File Systems Developers”
Sent: Sunday, November 04, 2001 12:28 PM
Subject: [ntfsd] RE: Help on a crash dump

> Wil,
>
> What version of the debugger are you using? I haven’t seen recent
versions
> displaying sign-extended values, so if you aren’t using the current stuff,
> you really should upgrade (http://www.microsoft.com/ddk/debugging
> http: .)
>
> Use the trap frame information with the “.trap ” command (in this
> case 0xf04e6c38) so you can see what actually happened. Also, confirm
that
> you are using the correct symbols, since the stack trace you sent looks
like
> garbage to me (it isn’t very likely that IopPnpDispatch would be in the
> trace before NtfsQueryDirectory, and it isn’t likely that
NtfsCommonCleanup
> would EVER be called from NtfsRemoveCachedLcn.) I can certainly believe
the
> ExAcquireResource* things since they are “standard” stuff, but given the
> rest of what looks dubious, I wouldn’t be trying to draw conclusions from
> it.
>
> If you can’t make any sense of it, I’ll be happy to look at it - I’m
always
> looking for interesting dumps to use in my kernel debug lab class.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com http:</http:>
>
>
> -----Original Message-----
> From: william [mailto:xxxxx@javabear.com]
> Sent: Friday, November 02, 2001 3:46 PM
> To: File Systems Developers
> Subject: [ntfsd] Help on a crash dump
>
> Was wondering if anyone could give some pointers to the following stack
> trace to a crash dump.
> The system was loading up a file system filter driver. The crash seems to
> occur whenever a QueryDirectory call is made.
>
> Thanks,
>
> Will
>
> > kv
> fffffffff04e6c38 ffffffff804171a0 0000000000000000 0000000000000000
> 0000000000000000 NTOSKRNL!KiTrap0E+0x27b (FPO: [0,0] TrapFrame @ f04e6c38)
> fffffffff04e6cc4 ffffffff804166f4 fffffffff04e7050 fffffffff04e7050
> 0000000000000000 NTOSKRNL!@ExpFindCurrentThread@8+0x136 (EBP)
> fffffffff04e6cdc ffffffff80416620 ffffffff810e6c14 0000000000000001
> fffffffff04e7000 NTOSKRNL!ExpAcquireResourceSharedLite+0xd1 (EBP)
> fffffffff04e6cec ffffffffbff33cc6 ffffffff810e6c14 0000000000000001
> ffffffffac017fdc NTOSKRNL!ExAcquireResourceSharedLite+0x43 (EBP)
> fffffffff04e6cfc ffffffffbff3161b fffffffff04e7050 ffffffff810e6810
> 0000000000000001 NTFS!NtfsCommonCleanup+0xfffffffffffeadf8 (FPO: [3,0,1])
> fffffffff04e7000 ffffffffbff43ac3 fffffffff04e7050 ffffffffac017e70
> 0000000000000000 NTFS!NtfsRemoveCachedLcn+0x14 (EBP)
> fffffffff04e717c fffffffff13f9269 ffffffffac017e70 fffffffff04e74d8
> ffffffff814a0800 NTFS!NtfsQueryDirectory+0x1031b (EBP)
> fffffffff04e7190 ffffffff804e534c ffffffffac017e70 fffffffff04e74d8
> ffffffff810e6740 MPMON!0xFFFFFFFFF13F9269 (No FPO)
> fffffffff04e7324 ffffffff8044f0f2 ffffffff81484430 0000000000000000
> fffffffff04e73d0 NTOSKRNL!IopPnPDispatch+0x48dc6 (EBP)
> fffffffff04e7390 ffffffff8049a7fb 0000000000000000 fffffffff04e7400
> 0000000000000040 NTOSKRNL!ObpLookupObjectName+0x43d (EBP)
> fffffffff04e74a0 ffffffff804b6fc9 0000000000000000 0000000000000000
> fffffffff04e7501 NTOSKRNL!NtLockVirtualMemory+0xbb (EBP)
> fffffffff04e7614 ffffffff80462cf1 0000000000daeda8 0000000000daed80
> 0000000000000001 NTOSKRNL!@xHalIoAssignDriveLetters@16+0xfffffffffffebf7b
> (EBP)
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@javabear.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:>