DISPATCH_LEVEL and CcCopyWrite

NTFSD
1

My FSD got an IRP_MJ_WRITE today at DISPATCH_LEVEL Irql, and the FSD tried
to call CcCopyWrite, and BSOD (of course). I haven’t seen this in testing
before (and I have not tried Driver Verifier yet with it being set to make
all tests at DISPATCH_LEVEL). I noticed in MSDN doc for CcCopyWrite must
be called at IRQL < DISPATCH_LEVEL.

What am I supposed to do with an IRP that I get at dispatch_level? If I
requeue the IRP to a worker thread, it would be running at passive level,
no?

I’m still confused… and Thanks in advance…

Greg

2

How did you determine DISPATCH_LEVEL is the IRQL? The reason I ask is that the blue screen sometimes misleads you about the IRQL, and Windbg may as well. I don’t remember all the details of this, but if I saw it I’d recognize it.

Check for IRP_MN_DPC in irpStack->MinorFunction. (I thought this was deprecated and not used anymore?)

Also, send the list a stack trace.

-----Original Message-----
From: Greg Pearce [mailto:xxxxx@filetek.com]
Sent: Wednesday, July 24, 2002 1:19 PM
To: File Systems Developers
Subject: [ntfsd] DISPATCH_LEVEL and CcCopyWrite

My FSD got an IRP_MJ_WRITE today at DISPATCH_LEVEL Irql, and the FSD tried
to call CcCopyWrite, and BSOD (of course). I haven’t seen this in testing
before (and I have not tried Driver Verifier yet with it being set to make
all tests at DISPATCH_LEVEL). I noticed in MSDN doc for CcCopyWrite must
be called at IRQL < DISPATCH_LEVEL.

What am I supposed to do with an IRP that I get at dispatch_level? If I
requeue the IRP to a worker thread, it would be running at passive level,
no?

I’m still confused… and Thanks in advance…

Greg

You are currently subscribed to ntfsd as: xxxxx@inin.com
To unsubscribe send a blank email to %%email.unsub%%

3

Greg,

DISPATCH_LEVEL requests are no longer legitimate - someone else is calling
you incorrectly and you should flag the bug.

In the interim, what you do is what ANY good driver would do: mark the IRP
as pending, queue it, and return STATUS_PENDING. Anyone calling at IRQL
DISPATCH_LEVEL should expect nothing more anyhow.

Of course, the pain in the neck part is that it means you have to have a
work routine to handle this unusual case.

Regards,

Tony

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

Hope to see you at the next OSR file systems class in San Jose, CA September
16, 2002!

-----Original Message-----
From: Greg Pearce [mailto:xxxxx@filetek.com]
Sent: Wednesday, July 24, 2002 2:19 PM
To: File Systems Developers
Subject: [ntfsd] DISPATCH_LEVEL and CcCopyWrite

My FSD got an IRP_MJ_WRITE today at DISPATCH_LEVEL Irql, and the FSD tried
to call CcCopyWrite, and BSOD (of course). I haven’t seen this in testing
before (and I have not tried Driver Verifier yet with it being set to make
all tests at DISPATCH_LEVEL). I noticed in MSDN doc for CcCopyWrite must
be called at IRQL < DISPATCH_LEVEL.

What am I supposed to do with an IRP that I get at dispatch_level? If I
requeue the IRP to a worker thread, it would be running at passive level,
no?

I’m still confused… and Thanks in advance…

Greg

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

4

Thanks for the reply Rob and Tony! I found the IRQL in WinDbg - here’s
the analyze -v output and the stack - thanks for taking a look at it…

I appreciate the advice on what to do with the IRP, too, Tony - thanks
again…

kd> !analyze -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: 00000011, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 80447555, address which referenced memory

Debugging Details:

WRITE_ADDRESS: 00000011

CURRENT_IRQL: 2

FAULTING_IP:
nt!MmCopyToCachedPage+4c0
80447555 ff4010 inc dword ptr [eax+0x10]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA_W

TRAP_FRAME: bb225890 – (.trap ffffffffbb225890)
ErrCode = 00000002
eax=00000001 ebx=e1000000 ecx=00000000 edx=00802800 esi=c0000000
edi=84da4668
eip=80447555 esp=bb225904 ebp=bb225994 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
nt!MmCopyToCachedPage+4c0:
80447555 ff4010 inc dword ptr [eax+0x10]
ds:0023:00000011=???
Resetting default context

LAST_CONTROL_TRANSFER: from 80411816 to 80447555

STACK_TEXT:
bb225994 80411816 00000000 bb01716f 00000000 nt!MmCopyToCachedPage+0x4c0
bb225a38 8040e253 ff3d3ac8 bb01716f bb225a98 nt!CcMapAndCopy+0x13e
bb225ae8 bbc66c1f ff4fd848 bb225b3c 0000fe95 nt!CcCopyWrite+0x41f
bb225b94 bbc665d3 87beb288 87beb31c 8185a5f0
ntsfsd!InitiateWriteFile+0x56d [g:\ntfsd\current\driver\fsdwrite.c @ 495]
bb225be8 bbc5f13d 87beb288 87beb31c 8185a5f0 ntsfsd!FsdWriteRequest+0xe6
[g:\ntfsd\current\driver\fsdwrite.c @ 137]
bb225c34 8041f61f 8185a5f0 87beb288 87beb288 ntsfsd!FsdDispatch+0xd9
[g:\ntfsd\current\driver\fsddisp.c @ 270]
bb225c48 8049c66f 87beb31c 00000000 87beb288 nt!IopfCallDriver+0x35
bb225c5c 804b623c 8185a5f0 87beb288 ff4fd848
nt!IopSynchronousServiceTail+0x60
bb225d38 804649a1 00000350 00000000 00000000 nt!NtWriteFile+0x67a
bb225d38 77f8286f 00000350 00000000 00000000 nt!KiSystemService+0xc4
0012f790 77e86702 00000350 00000000 00000000 ntdll!ZwWriteFile+0xb
0012f7fc 004549c5 00000350 010fc004 00010000 KERNEL32!WriteFile+0x111
WARNING: Stack unwind information not available. Following frames may be
wrong.
0012f8b0 00477478 0106d07c 00169d38 0012f914 EAS!+0x26fd
0012f950 00476f4f 01065fb4 03d22aa0 0106d07c EAS!+0xd9c
0012f978 00482d0d 01065fb4 03d22aa0 0106d07c EAS!+0x873
0012f9e0 00482a8e 01065fb4 03d22aa0 010f760c EAS!+0x28d1
0012fa4c 004820e8 01065fb4 005e63f4 0110c020 EAS!+0x2652
0012faa0 00494343 01065fb4 0012fd5c 01063218 EAS!+0x1cac
0012fac0 00494708 01063218 0012fc74 0052e853 EAS!+0x10fb
0012fbf4 00531840 0012fc60 dcbaabcd 0012fc20 EAS!+0x14c0
0012fc3c 005314bb 0012fc50 005314d3 0012fc6c EAS!+0x8e8ec
0012fc6c 00571372 00000591 00000004 00000000 EAS!+0x8e567
0012fc84 77e12e98 00070176 00000591 00000004 EAS!+0xce41e
0012fca4 77e130e0 01160fd5 00070176 00000591 USER32!UserCallWinProc+0x18
0012fd30 77e15824 0012fd5c 00000001 0051f51c
USER32!DispatchMessageWorker+0x2d0
0012fd3c 0051f51c 0012fd5c 0012fd00 00000008 USER32!DispatchMessageA+0xb
0012fda8 00491caf 00000000 0059f034 00133c8e EAS!+0x7c5c8
0012ff70 00401c70 00400000 00000000 00133c8e EAS!+0x597
0012ff88 00597347 00400000 00000000 00133c8e EAS!_GetExceptDLLinfo+0x243
0012ffb8 00000000 0059f034 77e97d08 0012f2fc EAS!+0xf43f3

FOLLOWUP_IP:
ntsfsd!InitiateWriteFile+56d
bbc66c1f 25ff000000 and eax,0xff

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: ntsfsd!InitiateWriteFile+56d

MODULE_NAME: ntsfsd

IMAGE_NAME: ntsfsd.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3d36fbd8

STACK_COMMAND: .trap ffffffffbb225890 ; kb

BUCKET_ID: 0xA_W_ntsfsd!InitiateWriteFile+56d

Followup: MachineOwner

5

Rob -

Sorry - I forgot to mention that IrpSp->MinorFunction = 0x00
(IRP_MN_NORMAL).

Regards,

Greg

6

Greg,

I think you are misinterpreting here.

The cache manager DOES use spin locks internally in some of its functions
because it presumes its data structures are from non-paged pool this should
be safe.

But notice that in your bug check your invalid address is 0x11. The EAX
register contains 0x1 and something at offset 0x10 from that is used in the
faulting instruction. Unfortunately for you, the process context in which
you are operating does not have anything mapped in on that page, so that
causes a page fault which ultimately leads to a crash in the system.

The fact that it is running at IRQL DISPATCH_LEVEL at the time of the crash
does not imply that you were called at DISPATCH_LEVEL (in fact, you can
check this within your own code).

I suspect this is a bug in your driver - you are passing something to this
Cc routine that is not properly initialized.

Regards,

Tony

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

Hope to see you at the next OSR file systems class in San Jose, CA September
16, 2002!

-----Original Message-----
From: Greg Pearce [mailto:xxxxx@filetek.com]
Sent: Wednesday, July 24, 2002 2:56 PM
To: File Systems Developers
Subject: [ntfsd] RE: DISPATCH_LEVEL and CcCopyWrite

Thanks for the reply Rob and Tony! I found the IRQL in WinDbg - here’s
the analyze -v output and the stack - thanks for taking a look at it…

I appreciate the advice on what to do with the IRP, too, Tony - thanks
again…

kd> !analyze -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: 00000011, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 80447555, address which referenced memory

Debugging Details:

WRITE_ADDRESS: 00000011

CURRENT_IRQL: 2

FAULTING_IP:
nt!MmCopyToCachedPage+4c0
80447555 ff4010 inc dword ptr [eax+0x10]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA_W

TRAP_FRAME: bb225890 – (.trap ffffffffbb225890)
ErrCode = 00000002
eax=00000001 ebx=e1000000 ecx=00000000 edx=00802800 esi=c0000000
edi=84da4668
eip=80447555 esp=bb225904 ebp=bb225994 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
nt!MmCopyToCachedPage+4c0:
80447555 ff4010 inc dword ptr [eax+0x10]
ds:0023:00000011=???
Resetting default context

LAST_CONTROL_TRANSFER: from 80411816 to 80447555

STACK_TEXT:
bb225994 80411816 00000000 bb01716f 00000000 nt!MmCopyToCachedPage+0x4c0
bb225a38 8040e253 ff3d3ac8 bb01716f bb225a98 nt!CcMapAndCopy+0x13e
bb225ae8 bbc66c1f ff4fd848 bb225b3c 0000fe95 nt!CcCopyWrite+0x41f
bb225b94 bbc665d3 87beb288 87beb31c 8185a5f0
ntsfsd!InitiateWriteFile+0x56d [g:\ntfsd\current\driver\fsdwrite.c @ 495]
bb225be8 bbc5f13d 87beb288 87beb31c 8185a5f0 ntsfsd!FsdWriteRequest+0xe6
[g:\ntfsd\current\driver\fsdwrite.c @ 137]
bb225c34 8041f61f 8185a5f0 87beb288 87beb288 ntsfsd!FsdDispatch+0xd9
[g:\ntfsd\current\driver\fsddisp.c @ 270]
bb225c48 8049c66f 87beb31c 00000000 87beb288 nt!IopfCallDriver+0x35
bb225c5c 804b623c 8185a5f0 87beb288 ff4fd848
nt!IopSynchronousServiceTail+0x60
bb225d38 804649a1 00000350 00000000 00000000 nt!NtWriteFile+0x67a
bb225d38 77f8286f 00000350 00000000 00000000 nt!KiSystemService+0xc4
0012f790 77e86702 00000350 00000000 00000000 ntdll!ZwWriteFile+0xb
0012f7fc 004549c5 00000350 010fc004 00010000 KERNEL32!WriteFile+0x111
WARNING: Stack unwind information not available. Following frames may be
wrong.
0012f8b0 00477478 0106d07c 00169d38 0012f914 EAS!+0x26fd
0012f950 00476f4f 01065fb4 03d22aa0 0106d07c EAS!+0xd9c
0012f978 00482d0d 01065fb4 03d22aa0 0106d07c EAS!+0x873
0012f9e0 00482a8e 01065fb4 03d22aa0 010f760c EAS!+0x28d1
0012fa4c 004820e8 01065fb4 005e63f4 0110c020 EAS!+0x2652
0012faa0 00494343 01065fb4 0012fd5c 01063218 EAS!+0x1cac
0012fac0 00494708 01063218 0012fc74 0052e853 EAS!+0x10fb
0012fbf4 00531840 0012fc60 dcbaabcd 0012fc20 EAS!+0x14c0
0012fc3c 005314bb 0012fc50 005314d3 0012fc6c EAS!+0x8e8ec
0012fc6c 00571372 00000591 00000004 00000000 EAS!+0x8e567
0012fc84 77e12e98 00070176 00000591 00000004 EAS!+0xce41e
0012fca4 77e130e0 01160fd5 00070176 00000591 USER32!UserCallWinProc+0x18
0012fd30 77e15824 0012fd5c 00000001 0051f51c
USER32!DispatchMessageWorker+0x2d0
0012fd3c 0051f51c 0012fd5c 0012fd00 00000008 USER32!DispatchMessageA+0xb
0012fda8 00491caf 00000000 0059f034 00133c8e EAS!+0x7c5c8
0012ff70 00401c70 00400000 00000000 00133c8e EAS!+0x597
0012ff88 00597347 00400000 00000000 00133c8e EAS!_GetExceptDLLinfo+0x243
0012ffb8 00000000 0059f034 77e97d08 0012f2fc EAS!+0xf43f3

FOLLOWUP_IP:
ntsfsd!InitiateWriteFile+56d
bbc66c1f 25ff000000 and eax,0xff

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: ntsfsd!InitiateWriteFile+56d

MODULE_NAME: ntsfsd

IMAGE_NAME: ntsfsd.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3d36fbd8

STACK_COMMAND: .trap ffffffffbb225890 ; kb

BUCKET_ID: 0xA_W_ntsfsd!InitiateWriteFile+56d

Followup: MachineOwner

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

7

Uh oh! Thanks for noticing that Tony - I totally missed it. I see that
my IrpSp->FileObject seems to be corrupted! The Fo->Type is 15096 and the
Fo->Size is -195 !!! The rest of it mostly looks ok. The other
parameters appear to be correct to CcCopyWrite. It’s trying to write for
length=0x10000, to ByteOffset=0xF5E95. The FileSize is also 0xF5E95,
AllocationSize=0xF6000.

I guess I have a smasher somewhere… now just exactly how to find it…
Anyone have any suggestions?

Thanks - Greg

8

ASSERTS are your friends. You might want to use them . And use PAGED_CODE()
macro too , and UNREFERENCED_PARAMETER() macro in conjunction with
pragma warning(error:4100)
pragma warning(error:4101)

A well placed ASSERT can save you wasting precious minutes into the
debugger.

They will save you a lot of devoloping time. At least they did for me. Adopt
defensive strategies while writing your code, its rewarding. Know your
compiler and use whatever facilites it offer to help you

Dan

“Greg Pearce” wrote in message news:xxxxx@ntfsd…
>
> Uh oh! Thanks for noticing that Tony - I totally missed it. I see that
> my IrpSp->FileObject seems to be corrupted! The Fo->Type is 15096 and the
> Fo->Size is -195 !!! The rest of it mostly looks ok. The other
> parameters appear to be correct to CcCopyWrite. It’s trying to write for
> length=0x10000, to ByteOffset=0xF5E95. The FileSize is also 0xF5E95,
> AllocationSize=0xF6000.
>
> I guess I have a smasher somewhere… now just exactly how to find it…
> Anyone have any suggestions?
>
> Thanks - Greg
>
>

9

Dan - Thanks for the excellent tips - I’ll do that right now!

Greg