very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
*finally* run it on Win2k, and immediately I started having problems. The
most persistent problem is an intermittent ASSERT from the io manager which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.
First, let me explain an assumption I made long ago: I assumed that
in the dispatch handler for an IRP_MJ_CREATE request, it would be ok for me
to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)
{
-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back through
me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking out
Win2K (note is seemed to work fine on NT4). Am I doing something completely
stupid here?

Anyways, *most* of the time, everything works fine in Win2K.
However, *sometimes* I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle for
a few seconds. It seems to occur most often as the system is unloading some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with **jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
****** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
****** Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

*** Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
*** Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit

kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)
ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffbc09870c ffffffffbfe787c2 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])
ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0, 0x00000005,
0xBC0987EC, 0x00000018) (EBP)
**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to the
file system driver. Here I query for FileStandardInformation.
ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)
**jts - here, I call a function which adds a record to a RtlGenericTable for
the file (the record includes the file’s full name, its size, possibly its
owner (if the file already exists). I’ve acquired a kernel mutext in the
dispatch routine to synchronize access to the table. Also in this function,
I call ZwCreateFile to attempt to open the target of the original open.
ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
**jts - QmCreate is my create dispatch routine. If certain conditions are
met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and then
calling a function (NcAddFileToCacheInCreateDispatch - see above).
ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])
ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO: [11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2
NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c (EBP)
000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

*** Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
*** Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit

kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4 FASTFAT!FatDeleteIrpContext_Real+0x28
(EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

*** Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit

kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction (FPO:
[1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel

Here’s my QmGetOpenFileInformation function, in case it helps:

NTSTATUS QmGetOpenFileInformation(PFILE_OBJECT pFile, PDEVICE_OBJECT
pVolDev, FILE_INFORMATION_CLASS InfoClass, void *pBuffer, int nBufferLength)
{
KEVENT event;
IO_STATUS_BLOCK stat;
PIRP pIrp;
PIO_STACK_LOCATION pStack;
NTSTATUS ntRet;

__try
{
__try
{
//initialize <file:> event to signal completion
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

//allocate <file:> a new irp
pIrp = IoAllocateIrp(pVolDev->StackSize, FALSE);

//set <file:> a completion routine to free the irp
IoSetCompletionRoutine(pIrp, QmDefaultComplete, 0, TRUE, TRUE, TRUE);

//setup <file:> the irp
pIrp->UserEvent = &event;
pIrp->AssociatedIrp.SystemBuffer = pBuffer;
pIrp->UserIosb = &stat;
pIrp->Tail.Overlay.Thread = KeGetCurrentThread();
pIrp->Tail.Overlay.OriginalFileObject = pFile;
pIrp->RequestorMode = KernelMode;
pIrp->Flags = 0;

//Set <file:> up the I/O stack location.
pStack = IoGetNextIrpStackLocation(pIrp);
pStack->MajorFunction = IRP_MJ_QUERY_INFORMATION;
pStack->DeviceObject = pVolDev;
pStack->FileObject = pFile;
pStack->Parameters.QueryFile.Length = nBufferLength;
pStack->Parameters.QueryFile.FileInformationClass = InfoClass;

//Send <file:> it to the FSD
IoCallDriver(pVolDev, pIrp);
KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, NULL);

ntRet = stat.Status;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
DEFAULT_EXCEPTION_HANDLER(“QmGetOpenFileInformation”);
ntRet = GetExceptionCode();
}
}
__finally
{

}

file://report <file:> the result
return ntRet;
}

-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
Sent: Wednesday, June 14, 2000 4:36 PM
To: File Systems Developers
Subject: [ntfsd] very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
finally run it on Win2k, and immediately I started having problems. The
most persistent problem is an intermittent ASSERT from the io manager which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.

First, let me explain an assumption I made long ago: I assumed that
in the dispatch handler for an IRP_MJ_CREATE request, it would be ok for me
to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)
{
-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back through
me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking out
Win2K (note is seemed to work fine on NT4). Am I doing something completely
stupid here?

Anyways, most of the time, everything works fine in Win2K.
However, sometimes I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle for
a few seconds. It seems to occur most often as the system is unloading some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
**** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
***Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
***Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit
> kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)
ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffbc09870c ffffffffbfe787c2 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])

ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0, 0x00000005,
0xBC0987EC, 0x00000018) (EBP)

**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to the
file system driver. Here I query for FileStandardInformation.

ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)

*jts - here, I call a function which adds a record to a RtlGenericTable for
the file (the record includes the file’s full name, its size, possibly its
owner (if the file already exists). I’ve acquired a kernel mutext in the
dispatch routine to synchronize access to the table. Also in this function,
I call ZwCreateFile to attempt to open the target of the original open.

ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
jts - QmCreate is my create dispatch routine. If certain conditions are
met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and then
calling a function (NcAddFileToCacheInCreateDispatch - see above).

ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])

ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO: [11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2
NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c (EBP)

000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit
> kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4 FASTFAT!FatDeleteIrpContext_Real+0x28
(EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit
> kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction (FPO:
[1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel</file:></file:></file:></file:></file:></file:></file:>

very stuck with a bug - very long and involvedWhen you are completing the
request by returning STATUS_PENDING, you should make sure that you have set
the IRP status code to STATUS_PENDING as well. Otherwise, The completion
process with ASSERT(). This looks like the assertion that you are seeing.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
Sent: Wednesday, June 14, 2000 1:36 PM
To: File Systems Developers
Subject: [ntfsd] very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
*finally* run it on Win2k, and immediately I started having problems. The
most persistent problem is an intermittent ASSERT from the io manager which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.

First, let me explain an assumption I made long ago: I assumed
that in the dispatch handler for an IRP_MJ_CREATE request, it would be ok
for me to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)

-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back through
me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this
file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking
out Win2K (note is seemed to work fine on NT4). Am I doing something
completely stupid here?

Anyways, *most* of the time, everything works fine in Win2K.
However, *sometimes* I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle for
a few seconds. It seems to occur most often as the system is unloading some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with **jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
****** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
****** Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

*** Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
*** Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit
> kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)
ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffbc09870c ffffffffbfe787c2
FASTFAT!FatCommonQueryInformation+0x2a0 (EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO:
[0,0,3])
ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0, 0x00000005,
0xBC0987EC, 0x00000018) (EBP)

**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to the
file system driver. Here I query for FileStandardInformation.

ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)

**jts - here, I call a function which adds a record to a RtlGenericTable
for the file (the record includes the file’s full name, its size, possibly
its owner (if the file already exists). I’ve acquired a kernel mutext in
the dispatch routine to synchronize access to the table. Also in this
function, I call ZwCreateFile to attempt to open the target of the original
open.

ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
**jts - QmCreate is my create dispatch routine. If certain conditions are
met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and then
calling a function (NcAddFileToCacheInCreateDispatch - see above).

ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO:
[0,0,3])
ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO: [11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2
NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c
(EBP)
000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

*** Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
*** Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit
> kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4 FASTFAT!FatDeleteIrpContext_Real+0x28
(EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
(EBP)
ffffffffed43fce0 ffffffffbfe966a6
FASTFAT!FatCommonQueryInformation+0x2a0 (EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

*** Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit
> kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction
(FPO: [1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffed43fce0 ffffffffbfe966a6
FASTFAT!FatCommonQueryInformation+0x2a0 (EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel

very stuck with a bug - very long and involvedCan we see your completion
routine?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
Sent: Wednesday, June 14, 2000 1:39 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

Here’s my QmGetOpenFileInformation function, in case it helps:

NTSTATUS QmGetOpenFileInformation(PFILE_OBJECT pFile, PDEVICE_OBJECT
pVolDev, FILE_INFORMATION_CLASS InfoClass, void *pBuffer, int nBufferLength)
{
KEVENT event;
IO_STATUS_BLOCK stat;
PIRP pIrp;
PIO_STACK_LOCATION pStack;
NTSTATUS ntRet;

__try
{
__try
{
//initialize event to signal completion
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

//allocate a new irp
pIrp = IoAllocateIrp(pVolDev->StackSize, FALSE);

//set a completion routine to free the irp
IoSetCompletionRoutine(pIrp, QmDefaultComplete, 0, TRUE, TRUE, TRUE);

//setup the irp
pIrp->UserEvent = &event;
pIrp->AssociatedIrp.SystemBuffer = pBuffer;
pIrp->UserIosb = &stat;
pIrp->Tail.Overlay.Thread = KeGetCurrentThread();
pIrp->Tail.Overlay.OriginalFileObject = pFile;
pIrp->RequestorMode = KernelMode;
pIrp->Flags = 0;

//Set up the I/O stack location.
pStack = IoGetNextIrpStackLocation(pIrp);
pStack->MajorFunction = IRP_MJ_QUERY_INFORMATION;
pStack->DeviceObject = pVolDev;
pStack->FileObject = pFile;
pStack->Parameters.QueryFile.Length = nBufferLength;
pStack->Parameters.QueryFile.FileInformationClass = InfoClass;

//Send it to the FSD
IoCallDriver(pVolDev, pIrp);
KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, NULL);

ntRet = stat.Status;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
DEFAULT_EXCEPTION_HANDLER(“QmGetOpenFileInformation”);
ntRet = GetExceptionCode();
}
}
__finally
{

}

file://report the result
return ntRet;
}
-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
Sent: Wednesday, June 14, 2000 4:36 PM
To: File Systems Developers
Subject: [ntfsd] very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
*finally* run it on Win2k, and immediately I started having problems. The
most persistent problem is an intermittent ASSERT from the io manager which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.

First, let me explain an assumption I made long ago: I assumed
that in the dispatch handler for an IRP_MJ_CREATE request, it would be ok
for me to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)

-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back
through me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this
file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking
out Win2K (note is seemed to work fine on NT4). Am I doing something
completely stupid here?

Anyways, *most* of the time, everything works fine in Win2K.
However, *sometimes* I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle for
a few seconds. It seems to occur most often as the system is unloading some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with **jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
****** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
****** Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

*** Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
*** Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit
> kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)
ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffbc09870c ffffffffbfe787c2
FASTFAT!FatCommonQueryInformation+0x2a0 (EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO:
[0,0,3])
ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0, 0x00000005,
0xBC0987EC, 0x00000018) (EBP)

**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to
the file system driver. Here I query for FileStandardInformation.

ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)

**jts - here, I call a function which adds a record to a RtlGenericTable
for the file (the record includes the file’s full name, its size, possibly
its owner (if the file already exists). I’ve acquired a kernel mutext in
the dispatch routine to synchronize access to the table. Also in this
function, I call ZwCreateFile to attempt to open the target of the original
open.

ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
**jts - QmCreate is my create dispatch routine. If certain conditions
are met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and then
calling a function (NcAddFileToCacheInCreateDispatch - see above).

ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO:
[0,0,3])
ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO:
[11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2
NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c
(EBP)
000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

*** Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
*** Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit
> kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4
FASTFAT!FatDeleteIrpContext_Real+0x28 (EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
(EBP)
ffffffffed43fce0 ffffffffbfe966a6
FASTFAT!FatCommonQueryInformation+0x2a0 (EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

*** Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit
> kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction
(FPO: [1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffed43fce0 ffffffffbfe966a6
FASTFAT!FatCommonQueryInformation+0x2a0 (EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel

But I’m not completing either of these requests, the fat fsd is… (BTW I
though it was illegal to complete a reqest with STATUS_PENDING)

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, June 14, 2000 4:56 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

When you are completing the request by returning STATUS_PENDING, you should
make sure that you have set the IRP status code to STATUS_PENDING as well.
Otherwise, The completion process with ASSERT(). This looks like the
assertion that you are seeing.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
Sent: Wednesday, June 14, 2000 1:36 PM
To: File Systems Developers
Subject: [ntfsd] very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
*finally* run it on Win2k, and immediately I started having problems. The
most persistent problem is an intermittent ASSERT from the io manager which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.

First, let me explain an assumption I made long ago: I assumed that
in the dispatch handler for an IRP_MJ_CREATE request, it would be ok for me
to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)
{
-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back through
me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking out
Win2K (note is seemed to work fine on NT4). Am I doing something completely
stupid here?

Anyways, *most* of the time, everything works fine in Win2K.
However, *sometimes* I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle for
a few seconds. It seems to occur most often as the system is unloading some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with **jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
****** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
****** Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

*** Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
*** Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit

kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)
ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffbc09870c ffffffffbfe787c2 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])

ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0, 0x00000005,
0xBC0987EC, 0x00000018) (EBP)

**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to the
file system driver. Here I query for FileStandardInformation.

ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)

**jts - here, I call a function which adds a record to a RtlGenericTable for
the file (the record includes the file’s full name, its size, possibly its
owner (if the file already exists). I’ve acquired a kernel mutext in the
dispatch routine to synchronize access to the table. Also in this function,
I call ZwCreateFile to attempt to open the target of the original open.

ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
**jts - QmCreate is my create dispatch routine. If certain conditions are
met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and then
calling a function (NcAddFileToCacheInCreateDispatch - see above).

ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])

ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO: [11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2
NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c (EBP)

000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

*** Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
*** Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit

kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4 FASTFAT!FatDeleteIrpContext_Real+0x28
(EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

*** Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit

kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction (FPO:
[1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel

certainly (Note that the weird MDL unmapping is not relevent for the
particular request that is causing the problem (IRP_QUER_INFORMATION. That
block gets executed for the completion of an IRP_MJ_QUERY_SECURITY irp (and
I’m not sure I’m not screwing up here, either):

//completion <file:> routine which simply frees up a driver
created IRP which
//was <file:> sent to some other driver
NTSTATUS QmDefaultComplete(PDEVICE_OBJECT pDev, PIRP pIrp, PVOID Context)
{
PVOID pPtr;

pIrp->UserIosb = pIrp->IoStatus;

//if <file:> there is an MDL, we must unmap/unlock it
if (pIrp->MdlAddress != NULL)
{
pPtr = MmGetSystemAddressForMdl(pIrp->MdlAddress);
if (pPtr != NULL)
{
MmUnmapLockedPages(pPtr, pIrp->MdlAddress);
MmUnlockPages(pIrp->MdlAddress);
IoFreeMdl(pIrp->MdlAddress);
}
pIrp->MdlAddress = NULL;
}

// Set the user event - wakes up the mainline code doing this.
KeSetEvent(pIrp->UserEvent, 0, FALSE);

// Free the IRP now that we are done with it.
IoFreeIrp(pIrp);

return STATUS_MORE_PROCESSING_REQUIRED;
}

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, June 14, 2000 5:03 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

Can we see your completion routine?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
Sent: Wednesday, June 14, 2000 1:39 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

Here’s my QmGetOpenFileInformation function, in case it helps:

NTSTATUS QmGetOpenFileInformation(PFILE_OBJECT pFile, PDEVICE_OBJECT
pVolDev, FILE_INFORMATION_CLASS InfoClass, void pBuffer, int nBufferLength)
{
KEVENT event;
IO_STATUS_BLOCK stat;
PIRP pIrp;
PIO_STACK_LOCATION pStack;
NTSTATUS ntRet;

try
{
try
{
//initialize <file:> event to signal completion
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

//allocate <file:> a new irp
pIrp = IoAllocateIrp(pVolDev->StackSize, FALSE);

//set <file:> a completion routine to free the irp
IoSetCompletionRoutine(pIrp, QmDefaultComplete, 0, TRUE, TRUE, TRUE);

//setup <file:> the irp
pIrp->UserEvent = &event;
pIrp->AssociatedIrp.SystemBuffer = pBuffer;
pIrp->UserIosb = &stat;
pIrp->Tail.Overlay.Thread = KeGetCurrentThread();
pIrp->Tail.Overlay.OriginalFileObject = pFile;
pIrp->RequestorMode = KernelMode;
pIrp->Flags = 0;

//Set <file:> up the I/O stack location.
pStack = IoGetNextIrpStackLocation(pIrp);
pStack->MajorFunction = IRP_MJ_QUERY_INFORMATION;
pStack->DeviceObject = pVolDev;
pStack->FileObject = pFile;
pStack->Parameters.QueryFile.Length = nBufferLength;
pStack->Parameters.QueryFile.FileInformationClass = InfoClass;

//Send <file:> it to the FSD
IoCallDriver(pVolDev, pIrp);
KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, NULL);

ntRet = stat.Status;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
DEFAULT_EXCEPTION_HANDLER(“QmGetOpenFileInformation”);
ntRet = GetExceptionCode();
}
}
__finally
{

}

file://report <file:> the result
return ntRet;
}

-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
Sent: Wednesday, June 14, 2000 4:36 PM
To: File Systems Developers
Subject: [ntfsd] very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
finally run it on Win2k, and immediately I started having problems. The
most persistent problem is an intermittent ASSERT from the io manager which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.

First, let me explain an assumption I made long ago: I assumed that
in the dispatch handler for an IRP_MJ_CREATE request, it would be ok for me
to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)
{
-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back through
me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking out
Win2K (note is seemed to work fine on NT4). Am I doing something completely
stupid here?

Anyways, most of the time, everything works fine in Win2K.
However, sometimes I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle for
a few seconds. It seems to occur most often as the system is unloading some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
***Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
***Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit
> kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)
ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffbc09870c ffffffffbfe787c2 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])

ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0, 0x00000005,
0xBC0987EC, 0x00000018) (EBP)

**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to the
file system driver. Here I query for FileStandardInformation.

ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)

*jts - here, I call a function which adds a record to a RtlGenericTable for
the file (the record includes the file’s full name, its size, possibly its
owner (if the file already exists). I’ve acquired a kernel mutext in the
dispatch routine to synchronize access to the table. Also in this function,
I call ZwCreateFile to attempt to open the target of the original open.

ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
jts - QmCreate is my create dispatch routine. If certain conditions are
met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and then
calling a function (NcAddFileToCacheInCreateDispatch - see above).

ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])

ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO: [11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2
NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c (EBP)

000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit
> kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4 FASTFAT!FatDeleteIrpContext_Real+0x28
(EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit
> kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction (FPO:
[1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel</file:></file:></file:></file:></file:></file:></file:></file:></file:></file:>

This problem cannot have anything to do with his completion routine because
this check occurs early in the completion sequence (that is, before his
completion routine has been called.) It is one of the standard checks in
IoCompleteRequest that is done to ensure the IRP has been properly set for
this case.

In reviewing the code through FAT that handles this, I note that FAT already
traps many cases where the status is STATUS_PENDING (oplocks, notably.) The
question is “what path is it walking through FAT that generates this case”.
Your stack trace indicates you are asking for type 0x5
(FileStandardInformation.)

If you trace FatCommonQueryInformation, you can see that it tracks the
“Status” of the IRP and sets it when it completes the IRP.
FatCompleteRequest_Real does nothing more than set the value of the Status
that is passed into it.

Note that FatQueryStandardInfo doesn’t return a value, nor does it affect
this Status. Thus, the only place this could be set is in
FatCommonQueryInformation. In scanning through this code, I looked at each
place where Status was set to something different and found the following:

try_return( Status = FatFsdPostRequest( IrpContext, Irp
));

Thus, this transfers control to the “finally” block where the IRP is
completed. Thus, my guess is that FAT is posting the request (which returns
STATUS_PENDING) because it cannot obtain the FCB lock on this file.

In turn, this is NOT triggering the “AbnormalTermination” routine’s logic,
so the IRP is being completed.

You can confirm this by looking at the output buffer. If the output buffer
has NOT been filled in, then you know it didn’t call the standard
information routine (in which case it must have gone down the post path.)

I hope this helps.

Regards,

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

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, June 14, 2000 5:03 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

Can we see your completion routine?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
Sent: Wednesday, June 14, 2000 1:39 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

Here’s my QmGetOpenFileInformation function, in case it helps:

NTSTATUS QmGetOpenFileInformation(PFILE_OBJECT pFile, PDEVICE_OBJECT
pVolDev, FILE_INFORMATION_CLASS InfoClass, void pBuffer, int nBufferLength)
{
KEVENT event;
IO_STATUS_BLOCK stat;
PIRP pIrp;
PIO_STACK_LOCATION pStack;
NTSTATUS ntRet;

try
{
try
{
//initialize <file:> event to signal completion
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

//allocate <file:> a new irp
pIrp = IoAllocateIrp(pVolDev->StackSize, FALSE);

//set <file:> a completion routine to free the irp
IoSetCompletionRoutine(pIrp, QmDefaultComplete, 0, TRUE, TRUE, TRUE);

//setup <file:> the irp
pIrp->UserEvent = &event;
pIrp->AssociatedIrp.SystemBuffer = pBuffer;
pIrp->UserIosb = &stat;
pIrp->Tail.Overlay.Thread = KeGetCurrentThread();
pIrp->Tail.Overlay.OriginalFileObject = pFile;
pIrp->RequestorMode = KernelMode;
pIrp->Flags = 0;

//Set <file:> up the I/O stack location.
pStack = IoGetNextIrpStackLocation(pIrp);
pStack->MajorFunction = IRP_MJ_QUERY_INFORMATION;
pStack->DeviceObject = pVolDev;
pStack->FileObject = pFile;
pStack->Parameters.QueryFile.Length = nBufferLength;
pStack->Parameters.QueryFile.FileInformationClass = InfoClass;

//Send <file:> it to the FSD
IoCallDriver(pVolDev, pIrp);
KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, NULL);

ntRet = stat.Status;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
DEFAULT_EXCEPTION_HANDLER(“QmGetOpenFileInformation”);
ntRet = GetExceptionCode();
}
}
__finally
{

}

file://report <file:> the result
return ntRet;
}

-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
Sent: Wednesday, June 14, 2000 4:36 PM
To: File Systems Developers
Subject: [ntfsd] very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
finally run it on Win2k, and immediately I started having problems. The
most persistent problem is an intermittent ASSERT from the io manager which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.

First, let me explain an assumption I made long ago: I assumed that
in the dispatch handler for an IRP_MJ_CREATE request, it would be ok for me
to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)
{
-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back through
me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking out
Win2K (note is seemed to work fine on NT4). Am I doing something completely
stupid here?

Anyways, most of the time, everything works fine in Win2K.
However, sometimes I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle for
a few seconds. It seems to occur most often as the system is unloading some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
*** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
***Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
***Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit
> kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)
ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffbc09870c ffffffffbfe787c2 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])

ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0, 0x00000005,
0xBC0987EC, 0x00000018) (EBP)

**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to the
file system driver. Here I query for FileStandardInformation.

ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)

*jts - here, I call a function which adds a record to a RtlGenericTable for
the file (the record includes the file’s full name, its size, possibly its
owner (if the file already exists). I’ve acquired a kernel mutext in the
dispatch routine to synchronize access to the table. Also in this function,
I call ZwCreateFile to attempt to open the target of the original open.

ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
jts - QmCreate is my create dispatch routine. If certain conditions are
met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and then
calling a function (NcAddFileToCacheInCreateDispatch - see above).

ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])

ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO: [11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2
NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c (EBP)

000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit
> kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4 FASTFAT!FatDeleteIrpContext_Real+0x28
(EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit
> kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction (FPO:
[1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel</file:></file:></file:></file:></file:></file:></file:></http:>

Your method for freeing an MDL is very ugly.
More correct method (taken right from the
IoCompleteRequest’s postrocessing) should be:

PMDL Mdl = Irp->MdlAddress;

while (Mdl != NULL)
{
MmUnlockPages(Mdl);
Mdl = Mdl>Next;
}

if (Irp->MdlAddress != NULL)
{
IoFreeMdl(Irp->MdlAddress);
}

The first part is for unlocking pages locked down at MDL creation.
Second part frees the MDL (and if it is mapped to system VA
MmUnmapLockedPages is also called)
Then the pages are completely unlocked, system VA is unmapped
and MDL is deallocated.

Paul

PS: I know some questions still remains.

-----P?vodn? zpr?va-----
Od: Smith, Joel [SMTP:xxxxx@ntpsoftware.com]
Odesl?no: 14. ?ervna 2000 23:14
Komu: File Systems Developers
P?edm?t: [ntfsd] RE: very stuck with a bug - very long and involved

certainly (Note that the weird MDL unmapping is not relevent for the
particular request that is causing the problem (IRP_QUER_INFORMATION.
That block gets executed for the completion of an IRP_MJ_QUERY_SECURITY
irp (and I’m not sure I’m not screwing up here, either):

//completion <file:> routine which simply frees up a driver
> created IRP which
> //was <file:> sent to some other driver
> NTSTATUS QmDefaultComplete(PDEVICE_OBJECT pDev, PIRP pIrp, PVOID Context)
> {
> PVOID pPtr;
>
> pIrp->UserIosb = pIrp->IoStatus;
>
> //if <file:> there is an MDL, we must unmap/unlock it
> if (pIrp->MdlAddress != NULL)
> {
> pPtr = MmGetSystemAddressForMdl(pIrp->MdlAddress);
> if (pPtr != NULL)
> {
> MmUnmapLockedPages(pPtr, pIrp->MdlAddress);
> MmUnlockPages(pIrp->MdlAddress);
> IoFreeMdl(pIrp->MdlAddress);
> }
> pIrp->MdlAddress = NULL;
> }
>
> // Set the user event - wakes up the mainline code doing this.
> KeSetEvent(pIrp->UserEvent, 0, FALSE);
>
> // Free the IRP now that we are done with it.
> IoFreeIrp(pIrp);
>
> return STATUS_MORE_PROCESSING_REQUIRED;
> }
>
> -----Original Message-----
> From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
> Sent: Wednesday, June 14, 2000 5:03 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: very stuck with a bug - very long and involved
>
>
>
> Can we see your completion routine?
>
> Jamey
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
> Sent: Wednesday, June 14, 2000 1:39 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: very stuck with a bug - very long and
> involved
>
>
> Here’s my QmGetOpenFileInformation function, in case it
> helps:
>
> NTSTATUS QmGetOpenFileInformation(PFILE_OBJECT pFile,
> PDEVICE_OBJECT pVolDev, FILE_INFORMATION_CLASS InfoClass, void pBuffer,
> int nBufferLength)
> {
> KEVENT event;
> IO_STATUS_BLOCK stat;
> PIRP pIrp;
> PIO_STACK_LOCATION pStack;
> NTSTATUS ntRet;
>
> try
> {
> try
> {
> //initialize <file:> event to signal
> completion
> KeInitializeEvent(&event, SynchronizationEvent, FALSE);
>
> //allocate <file:> a new irp
> pIrp = IoAllocateIrp(pVolDev->StackSize, FALSE);
>
> //set <file:> a completion routine to free the irp
> IoSetCompletionRoutine(pIrp, QmDefaultComplete, 0, TRUE,
> TRUE, TRUE);
>
> //setup <file:> the irp
> pIrp->UserEvent = &event;
> pIrp->AssociatedIrp.SystemBuffer = pBuffer;
> pIrp->UserIosb = &stat;
> pIrp->Tail.Overlay.Thread = KeGetCurrentThread();
> pIrp->Tail.Overlay.OriginalFileObject = pFile;
> pIrp->RequestorMode = KernelMode;
> pIrp->Flags = 0;
>
> //Set <file:> up the I/O stack location.
> pStack = IoGetNextIrpStackLocation(pIrp);
> pStack->MajorFunction = IRP_MJ_QUERY_INFORMATION;
> pStack->DeviceObject = pVolDev;
> pStack->FileObject = pFile;
> pStack->Parameters.QueryFile.Length = nBufferLength;
> pStack->Parameters.QueryFile.FileInformationClass =
> InfoClass;
>
> //Send <file:> it to the FSD
> IoCallDriver(pVolDev, pIrp);
> KeWaitForSingleObject(&event, Executive, KernelMode,
> TRUE, NULL);
>
> ntRet = stat.Status;
> }
> __except(EXCEPTION_EXECUTE_HANDLER)
> {
> DEFAULT_EXCEPTION_HANDLER(“QmGetOpenFileInformation”);
> ntRet = GetExceptionCode();
> }
> }
>__finally
> {
>
> }
>
> <file:> the result
> return ntRet;
> }
>
> -----Original Message-----
> From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
> Sent: Wednesday, June 14, 2000 4:36 PM
> To: File Systems Developers
> Subject: [ntfsd] very stuck with a bug - very long
> and involved
>
>
>
> Hello,
> I’ve been working on a file system filter.
> The filter has been running fairly well under NT4. However, the other
> day, I decided to finally run it on Win2k, and immediately I started
> having problems. The most persistent problem is an intermittent ASSERT
> from the io manager which quickly resolved into a system bugcheck. It
> looks (to my inexperienced eyes) that FASTFAT is completing an IRP with
> STATUS_PENDING and then competing the IRP again from a system worker
> thread. I suspect my filter driver is the cause of this errant behavior,
> but I don’t know what I am doing wrong.
>
> First, let me explain an assumption I made
> long ago: I assumed that in the dispatch handler for an IRP_MJ_CREATE
> request, it would be ok for me to try to open the target of the create in
> the dispatch handler:
>
> CreateDispatchHandler(dev, irp)
> {
> -if certain access rights have been
> requested:
>
> -figure out the targe file
> name
>
> --ZwCreate(TargetFileName)
> (recurses back through me, but, because of access requested, I just pass
> it through)
>
>
> -if the file already exists
> (open succeeded)
>
> -reference the
> handle
>
> -query the fsd for
> information on this file
>
> -derefererence file
>
> -close handle
>
> -pass IRP through to file system
> }
>
> It seems to be this recursive create
> behavior which is freaking out Win2K (note is seemed to work fine on NT4).
> Am I doing something completely stupid here?
>
> Anyways, most of the time, everything
> works fine in Win2K. However, sometimes I get an assertion, and then a
> crash. Most of the time, the assertion happends right after logon, if the
> system sits idle for a few seconds. It seems to occur most often as the
> system is unloading some other drivers. Here is the ASSERTION followed by
> a stack dump ( I’ve annotated the stack dump with jts comments:
>
> 440.600p> Cairole: Unbalanced call to CoInitialize
> for thread 600
> 'swmidi: Entering PnpDriverUnload
>** Unloaded driver (swmidi)
> Module Unload: SWMIDI.SYS
> ***Unloaded driver (DMusic)
> Module Unload: DMUSIC.SYS
> Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol
> loading deferred)
>
> Assertion failed: Irp->IoStatus.Status !=
> STATUS_PENDING
> ***Source File: D:\nt\private\ntos\io\iosubs.c,
> line 3297
>
> >
> Break, Ignore, Terminate Process or Terminate Thread
> (bipt)? b
> Execute ‘!cxr BC098390’ to dump context
> Hard coded breakpoint hit
> > kv
> ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint
> (FPO: [0,0,0])
> ffffffffbc098660 ffffffff804249cb
> NT!RtlAssert+0x9a (EBP)
> ffffffffbc098694 ffffffffbfe731f0
> NT!@IopfCompleteRequest@8+0x85 (EBP)
> ffffffffbc0986a0 ffffffffbfe78b4c
> FASTFAT!FatCompleteRequest_Real+0x64 (EBP)
> ffffffffbc09870c ffffffffbfe787c2
> FASTFAT!FatCommonQueryInformation+0x2a0 (EBP)
> ffffffffbc098750 ffffffff80424606
> FASTFAT!FatFsdQueryInformation+0x5a (EBP)
> ffffffffbc098768 ffffffffed28a1bf
> NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])
> ffffffffbc0987c0 ffffffffed289020
> QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0,
> 0x00000005, 0xBC0987EC, 0x00000018) (EBP)
>
>**jts - QmGetOpenFileInformation sends an
> IRP_MJ_QUERY_INFORMATION to the file system driver. Here I query for
> FileStandardInformation.
>
> ffffffffbc09886c ffffffffed288872
> QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
> 0xBC098894) (EBP)
>
> **jts - here, I call a function which adds a record
> to a RtlGenericTable for the file (the record includes the file’s full
> name, its size, possibly its owner (if the file already exists). I’ve
> acquired a kernel mutext in the dispatch routine to synchronize access to
> the table. Also in this function, I call ZwCreateFile to attempt to open
> the target of the original open.
>
> ffffffffbc0988f4 ffffffff80424606
> QMFILTER!QmCreate+0x145(0x81853C00, 0x81402548) (EBP)
>**jts - QmCreate is my create dispatch routine. If
> certain conditions are met (certain access rights are requested) I try to
> ascertain some information about the file. I do this by acquiring a
> kernel mutex and then calling a function (NcAddFileToCacheInCreateDispatch
> - see above).
>
> ffffffffbc09890c ffffffff8054106f
> NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])
> ffffffffbc098a8c ffffffff804967fe
> NT!IopParseDevice+0xa52 (EBP)
> ffffffffbc098afc ffffffff8056ceb1
> NT!ObpLookupObjectName+0x5f8 (EBP)
> ffffffffbc098c0c ffffffff80510351
> NT!ObOpenObjectByName+0x119 (EBP)
> ffffffffbc098ce0 ffffffff8051c4b3
> NT!IoCreateFile+0x425 (EBP)
> ffffffffbc098d24 ffffffff804b19ba
> NT!NtCreateFile+0x61 (EBP)
> ffffffffbc098d24 0000000077f7851b
> NT!KiSystemService+0x10a (FPO: [0,3] TrapFrame @ bc098d64)
> 000000000573f578 0000000077e6ec35
> NTDLL!ZwCreateFile+0xb (FPO: [11,0,0])
> 000000000573f614 0000000075bfff2c
> KERNEL32!CreateFileW+0x343 (EBP)
> 000000000573f640 0000000075c00050
> NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
> 000000000573f650 0000000075c068eb
> NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
> 000000000573f6a4 0000000075c009f2
> NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0x3
> 1 (EBP)
> 000000000573f6bc 0000000075bfe06f
> NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z+0
> x22 (EBP)
> 000000000573f904 0000000075bfdf77
> NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
> 000000000573f90c 0000000075bfa23d
> NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
> 000000000573f91c 0000000075bb0856
> NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
> 000000000573f9e0 0000000075b7db04
> NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
> 000000000573ff84 0000000075b743ed
> NTMSSVC!?LmInitialize@@YGKXZ+0x11c (EBP)
> 000000000573ffb4 0000000077e5d4a3
> NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f (EBP)
> 000000000573ffec 0000000000000000
> KERNEL32!BaseThreadStart+0x52 (EBP)
>
>
> If I ignore this assertion, I get a second
> assertion:
>
> Assertion failed: IrpContext->NodeTypeCode ==
> FAT_NTC_IRP_CONTEXT
> Source File:
> D:\nt\private\ntos\fastfat\strucsup.c, line 1986
>
> >
> Break, Ignore, Terminate Process or Terminate Thread
> (bipt)? b
> Execute ‘!cxr ED43F974’ to dump context
> Hard coded breakpoint hit
> > kv
> ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint
> (FPO: [0,0,0])
> ffffffffed43fc44 ffffffffbfe71f9c
> NT!RtlAssert+0x9a (EBP)
> ffffffffed43fc64 ffffffffbfe731c4
> FASTFAT!FatDeleteIrpContext_Real+0x28 (EBP)
> ffffffffed43fc74 ffffffffbfe78b4c
> FASTFAT!FatCompleteRequest_Real+0x38 (EBP)
> ffffffffed43fce0 ffffffffbfe966a6
> FASTFAT!FatCommonQueryInformation+0x2a0 (EBP)
> ffffffffed43fd40 ffffffff8041beae
> FASTFAT!FatFspDispatch+0x10b (EBP)
> ffffffffed43fda8 ffffffff8049d5a2
> NT!ExpWorkerThread+0x106 (EBP)
> ffffffffed43fddc ffffffff804b70aa
> NT!PspSystemThreadStartup+0x54 (EBP)
> 0000000000000000 0000000000000000
> NT!KiThreadStartup+0x16 (No FPO)
>
> If I ignore this assertion, I get a
> bugcheck:
>
> *** Fatal System Error: 0x00000044
>
> (0x81402288,0x00000CCA,0x00000000,0x00000000)
>
> Hard coded breakpoint hit
> > kv
> ffffffffed43f878 ffffffff80438523
> NT!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
> ffffffffed43f8a8 ffffffff80438b01
> NT!KiBugCheckDebugBreak+0x31 (EBP)
> ffffffffed43fc30 ffffffff80424978
> NT!KeBugCheckEx+0x37b (EBP)
> ffffffffed43fc68 ffffffffbfe731f0
> NT!@IopfCompleteRequest@8+0x32 (EBP)
> ffffffffed43fc74 ffffffffbfe78b4c
> FASTFAT!FatCompleteRequest_Real+0x64 (EBP)
> ffffffffed43fce0 ffffffffbfe966a6
> FASTFAT!FatCommonQueryInformation+0x2a0 (EBP)
> ffffffffed43fd40 ffffffff8041beae
> FASTFAT!FatFspDispatch+0x10b (EBP)
> ffffffffed43fda8 ffffffff8049d5a2
> NT!ExpWorkerThread+0x106 (EBP)
> ffffffffed43fddc ffffffff804b70aa
> NT!PspSystemThreadStartup+0x54 (EBP)
> 0000000000000000 0000000000000000
> NT!KiThreadStartup+0x16 (No FPO)
>
> I figure somehow I’ve bolloxed up the file
> system driver. Unfortuneately, I haven’t the skill and knowledge to see
> what I’ve done wrong. I’m hoping its glaringly obvious to one of you, and
> you can save me a lot of time by telling me just what I’ve done wrong!
>
> Thanks,
> Joel
>
>
>
></file:></file:></file:></file:></file:></file:></file:></file:></file:></file:>

thanks - I wrote that routine a couple months ago, while I was even greener
than I am now and haven’t looked back (it never seemed to cause problems)!

-Joel

-----Original Message-----
From: Pavel Hrdina [mailto:xxxxx@sodatsw.cz]
Sent: Wednesday, June 14, 2000 5:47 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

Your method for freeing an MDL is very ugly.
More correct method (taken right from the
IoCompleteRequest’s postrocessing) should be:

PMDL Mdl = Irp->MdlAddress;

while (Mdl != NULL)
{
MmUnlockPages(Mdl);
Mdl = Mdl>Next;
}

if (Irp->MdlAddress != NULL)
{
IoFreeMdl(Irp->MdlAddress);
}

The first part is for unlocking pages locked down at MDL creation.
Second part frees the MDL (and if it is mapped to system VA
MmUnmapLockedPages is also called)
Then the pages are completely unlocked, system VA is unmapped
and MDL is deallocated.

Paul

PS: I know some questions still remains.
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

fastfat has a bug and you should work around this:

I = IoAllocateIrp(StackSize, FALSE);
// …
ioStackLocation = IoGetNextIrpStackLocation(I);
ioStackLocation->MajorFunction = IRP_MJ_QUERY_INFORMATION;
ioStackLocation->MinorFunction = 0;
// …
I->AssociatedIrp.SystemBuffer = address;
ioStackLocation->Parameters.QueryFile.Length = sizeof(FILE_STANDARD_INFORMATION);
ioStackLocation->Parameters.QueryFile.FileInformationClass = FileStandardInformation;

IoSetCompletionRoutine(I, IoCompletion, NULL, TRUE, TRUE, TRUE);

// Start working around FASTFAT bug
pFCB = (PFSRTL_COMMON_FCB_HEADER)pFile->FsContext;
ExAcquireResourceExclusiveLite(pFCB->MainResource,TRUE);
// …

ntStatus = IoCallDriver(pFSD, I);
if (ntStatus == STATUS_PENDING)
KeWaitForSingleObject(pEvent,Executive,KernelMode,TRUE,NULL);

// End working around
ExReleaseResourceForThreadLite(pFCB->MainResource,
ExGetCurrentResourceThread());
// …

Regards,
Max

??: Smith, Joel[SMTP:xxxxx@ntpsoftware.com]
???: 15 ??? 2000 ?. 0:35
???: File Systems Developers
???: [ntfsd] very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
*finally* run it on Win2k, and immediately I started having problems. The
most persistent problem is an intermittent ASSERT from the io manager which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.
First, let me explain an assumption I made long ago: I assumed that
in the dispatch handler for an IRP_MJ_CREATE request, it would be ok for me
to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)
{
-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back through
me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking out
Win2K (note is seemed to work fine on NT4). Am I doing something completely
stupid here?

Anyways, *most* of the time, everything works fine in Win2K.
However, *sometimes* I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle for
a few seconds. It seems to occur most often as the system is unloading some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with **jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
****** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
****** Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

*** Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
*** Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit

kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)
ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffbc09870c ffffffffbfe787c2 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])
ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0, 0x00000005,
0xBC0987EC, 0x00000018) (EBP)
**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to the
file system driver. Here I query for FileStandardInformation.
ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)
**jts - here, I call a function which adds a record to a RtlGenericTable for
the file (the record includes the file’s full name, its size, possibly its
owner (if the file already exists). I’ve acquired a kernel mutext in the
dispatch routine to synchronize access to the table. Also in this function,
I call ZwCreateFile to attempt to open the target of the original open.
ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
**jts - QmCreate is my create dispatch routine. If certain conditions are
met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and then
calling a function (NcAddFileToCacheInCreateDispatch - see above).
ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])
ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO: [11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2
NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c (EBP)
000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

*** Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
*** Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit

kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4 FASTFAT!FatDeleteIrpContext_Real+0x28
(EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

*** Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit

kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction (FPO:
[1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel

<???: ATT00000.html>>

Hi,

Are you talking about fastfat for Win2K or fastfat in general ? Would it be
wise to claim the resources anyway ?

With kind regards,

Bartjan Wattel

At 6/15/00 09:58 AM +0000, you wrote:

fastfat has a bug and you should work around this:

I = IoAllocateIrp(StackSize, FALSE);
// …
ioStackLocation = IoGetNextIrpStackLocation(I);
ioStackLocation->MajorFunction = IRP_MJ_QUERY_INFORMATION;
ioStackLocation->MinorFunction = 0;
// …
I->AssociatedIrp.SystemBuffer = address;
ioStackLocation->Parameters.QueryFile.Length =
sizeof(FILE_STANDARD_INFORMATION);
ioStackLocation->Parameters.QueryFile.FileInformationClass =
FileStandardInformation;

IoSetCompletionRoutine(I, IoCompletion, NULL, TRUE, TRUE, TRUE);

// Start working around FASTFAT bug
pFCB = (PFSRTL_COMMON_FCB_HEADER)pFile->FsContext;
ExAcquireResourceExclusiveLite(pFCB->MainResource,TRUE);
// …

ntStatus = IoCallDriver(pFSD, I);
if (ntStatus == STATUS_PENDING)
KeWaitForSingleObject(pEvent,Executive,KernelMode,TRUE,NULL);

// End working around
ExReleaseResourceForThreadLite(pFCB->MainResource,
ExGetCurrentResourceThread());
// …

Regards,
Max

---

??: Smith, Joel[SMTP:xxxxx@ntpsoftware.com]
???: 15 ??? 2000 ?. 0:35
???: File Systems Developers
???: [ntfsd] very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
*finally* run it on Win2k, and immediately I started having problems. The
most persistent problem is an intermittent ASSERT from the io manager which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.
First, let me explain an assumption I made long ago: I assumed that
in the dispatch handler for an IRP_MJ_CREATE request, it would be ok for me
to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)
{
-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back through
me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking out
Win2K (note is seemed to work fine on NT4). Am I doing something completely
stupid here?

Anyways, *most* of the time, everything works fine in Win2K.
However, *sometimes* I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle for
a few seconds. It seems to occur most often as the system is unloading some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with **jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
****** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
****** Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

*** Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
*** Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit
> kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)
ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffbc09870c ffffffffbfe787c2 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])
ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0, 0x00000005,
0xBC0987EC, 0x00000018) (EBP)
**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to the
file system driver. Here I query for FileStandardInformation.
ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)
**jts - here, I call a function which adds a record to a RtlGenericTable for
the file (the record includes the file’s full name, its size, possibly its
owner (if the file already exists). I’ve acquired a kernel mutext in the
dispatch routine to synchronize access to the table. Also in this function,
I call ZwCreateFile to attempt to open the target of the original open.
ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
**jts - QmCreate is my create dispatch routine. If certain conditions are
met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and then
calling a function (NcAddFileToCacheInCreateDispatch - see above).
ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])
ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO: [11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2

NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c (EBP)
000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

*** Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
*** Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit
> kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4 FASTFAT!FatDeleteIrpContext_Real+0x28
(EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

*** Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit
> kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction (FPO:
[1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel

<???: ATT00000.html>>

With kind regards,

Bartjan Wattel

I don’t know whether this bug is fixed in Win2K.

??: Bartjan Wattel[SMTP:xxxxx@wxs.nl]
???: 15 ??? 2000 ?. 11:28
???: File Systems Developers
???: [ntfsd] Re: very stuck with a bug - very long and involved

Hi,

Are you talking about fastfat for Win2K or fastfat in general ? Would it be
wise to claim the resources anyway ?

With kind regards,

Bartjan Wattel

At 6/15/00 09:58 AM +0000, you wrote:

fastfat has a bug and you should work around this:

I = IoAllocateIrp(StackSize, FALSE);
// …
ioStackLocation = IoGetNextIrpStackLocation(I);
ioStackLocation->MajorFunction = IRP_MJ_QUERY_INFORMATION;
ioStackLocation->MinorFunction = 0;
// …
I->AssociatedIrp.SystemBuffer = address;
ioStackLocation->Parameters.QueryFile.Length =
sizeof(FILE_STANDARD_INFORMATION);
ioStackLocation->Parameters.QueryFile.FileInformationClass =
FileStandardInformation;

IoSetCompletionRoutine(I, IoCompletion, NULL, TRUE, TRUE, TRUE);

// Start working around FASTFAT bug
pFCB = (PFSRTL_COMMON_FCB_HEADER)pFile->FsContext;
ExAcquireResourceExclusiveLite(pFCB->MainResource,TRUE);
// …

ntStatus = IoCallDriver(pFSD, I);
if (ntStatus == STATUS_PENDING)
KeWaitForSingleObject(pEvent,Executive,KernelMode,TRUE,NULL);

// End working around
ExReleaseResourceForThreadLite(pFCB->MainResource,
ExGetCurrentResourceThread());
// …

Regards,
Max

---

??: Smith, Joel[SMTP:xxxxx@ntpsoftware.com]
???: 15 ??? 2000 ?. 0:35
???: File Systems Developers
???: [ntfsd] very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
*finally* run it on Win2k, and immediately I started having problems. The
most persistent problem is an intermittent ASSERT from the io manager which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.
First, let me explain an assumption I made long ago: I assumed that
in the dispatch handler for an IRP_MJ_CREATE request, it would be ok for me
to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)
{
-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back through
me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking out
Win2K (note is seemed to work fine on NT4). Am I doing something completely
stupid here?

Anyways, *most* of the time, everything works fine in Win2K.
However, *sometimes* I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle for
a few seconds. It seems to occur most often as the system is unloading some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with **jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
****** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
****** Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

*** Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
*** Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit
> kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)
ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffbc09870c ffffffffbfe787c2 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])
ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0, 0x00000005,
0xBC0987EC, 0x00000018) (EBP)
**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to the
file system driver. Here I query for FileStandardInformation.
ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)
**jts - here, I call a function which adds a record to a RtlGenericTable for
the file (the record includes the file’s full name, its size, possibly its
owner (if the file already exists). I’ve acquired a kernel mutext in the
dispatch routine to synchronize access to the table. Also in this function,
I call ZwCreateFile to attempt to open the target of the original open.
ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
**jts - QmCreate is my create dispatch routine. If certain conditions are
met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and then
calling a function (NcAddFileToCacheInCreateDispatch - see above).
ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])
ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO: [11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2

NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c (EBP)
000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

*** Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
*** Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit
> kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4 FASTFAT!FatDeleteIrpContext_Real+0x28
(EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

*** Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit
> kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction (FPO:
[1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel

<???: ATT00000.html>>

With kind regards,

Bartjan Wattel

You are currently subscribed to ntfsd as: xxxxx@paragon.ru
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

Max,
THANK YOU! I have been trying to figure out what’s wrong with my
filter for days now. I had begun to suspect a file system bug and was
dreading a day of FAT file system driver debugging today - and I arrived to
a fix in my inbox!!
BTW the bug is in Win2k FastFat. I wasn’t aware that it was present
in NT4 at all. I was having an intermittent ‘deadlock’ under NT4, but not
the bugchecks I was getting under Win2k. Your fixed has done away with the
Win2K bug checks and hopefully will resolve my NT4 deadlock as well (haven’t
tested that yet).
Thanks again.

-Joel

-----Original Message-----
From: xxxxx@paragon.ru [mailto:xxxxx@paragon.ru]
Sent: Thursday, June 15, 2000 1:58 AM
To: File Systems Developers
Subject: Re: [ntfsd] very stuck with a bug - very long and involved

fastfat has a bug and you should work around this:

I = IoAllocateIrp(StackSize, FALSE);
// …
ioStackLocation = IoGetNextIrpStackLocation(I);
ioStackLocation->MajorFunction = IRP_MJ_QUERY_INFORMATION;
ioStackLocation->MinorFunction = 0;
// …
I->AssociatedIrp.SystemBuffer = address;
ioStackLocation->Parameters.QueryFile.Length =
sizeof(FILE_STANDARD_INFORMATION);
ioStackLocation->Parameters.QueryFile.FileInformationClass =
FileStandardInformation;

IoSetCompletionRoutine(I, IoCompletion, NULL, TRUE, TRUE, TRUE);

// Start working around FASTFAT bug
pFCB = (PFSRTL_COMMON_FCB_HEADER)pFile->FsContext;
ExAcquireResourceExclusiveLite(pFCB->MainResource,TRUE);
// …

ntStatus = IoCallDriver(pFSD, I);
if (ntStatus == STATUS_PENDING)
KeWaitForSingleObject(pEvent,Executive,KernelMode,TRUE,NULL);

// End working around
ExReleaseResourceForThreadLite(pFCB->MainResource,
ExGetCurrentResourceThread());
// …

Regards,
Max

??: Smith, Joel[SMTP:xxxxx@ntpsoftware.com]
???: 15 ??? 2000 ?. 0:35
???: File Systems Developers
???: [ntfsd] very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
*finally* run it on Win2k, and immediately I started having problems. The
most persistent problem is an intermittent ASSERT from the io manager which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.
First, let me explain an assumption I made long ago: I assumed that
in the dispatch handler for an IRP_MJ_CREATE request, it would be ok for me
to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)
{
-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back through
me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking out
Win2K (note is seemed to work fine on NT4). Am I doing something completely
stupid here?

Anyways, *most* of the time, everything works fine in Win2K.
However, *sometimes* I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle for
a few seconds. It seems to occur most often as the system is unloading some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with **jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
****** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
****** Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

*** Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
*** Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit

kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)
ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffbc09870c ffffffffbfe787c2 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])
ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0, 0x00000005,
0xBC0987EC, 0x00000018) (EBP)
**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to the
file system driver. Here I query for FileStandardInformation.
ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)
**jts - here, I call a function which adds a record to a RtlGenericTable for
the file (the record includes the file’s full name, its size, possibly its
owner (if the file already exists). I’ve acquired a kernel mutext in the
dispatch routine to synchronize access to the table. Also in this function,
I call ZwCreateFile to attempt to open the target of the original open.
ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
**jts - QmCreate is my create dispatch routine. If certain conditions are
met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and then
calling a function (NcAddFileToCacheInCreateDispatch - see above).
ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])
ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO: [11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2
NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c (EBP)
000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

*** Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
*** Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit

kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4 FASTFAT!FatDeleteIrpContext_Real+0x28
(EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

*** Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit

kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction (FPO:
[1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel

<???: ATT00000.html>>

Hi,

Should this workaround only be used when one rolls his own IRP, or should we
also be carefull when we call ZwXXXX functions ?

–
Bartjan.

At 6/15/00 09:37 AM -0400, Smith, Joel wrote:

Max,
??? THANK YOU!? I have been trying to figure out what’s wrong with my
filter
for days now.? I had begun to suspect a file system bug and was dreading a day
of FAT file system driver debugging today - and I arrived to a fix in my
inbox!!

??? BTW the bug is in Win2k FastFat.? I wasn’t aware that it was
present in
NT4 at all.? I was having an intermittent ‘deadlock’ under NT4, but not the
bugchecks I was getting under Win2k.? Your fixed has done away with the Win2K
bug checks and hopefully will resolve my NT4 deadlock as well (haven’t tested
that yet).

??? Thanks again.

-Joel

-----Original Message-----
From: xxxxx@paragon.ru [mailto:xxxxxmailto:xxxxx@paragon.ru]
Sent: Thursday, June 15, 2000 1:58 AM
To: File Systems Developers
Subject: Re: [ntfsd] very stuck with a bug - very long and involved

fastfat has a bug and you should work around this:

I = IoAllocateIrp(StackSize, FALSE);
// …
ioStackLocation = IoGetNextIrpStackLocation(I);
ioStackLocation->MajorFunction = IRP_MJ_QUERY_INFORMATION;
ioStackLocation->MinorFunction = 0;
// …
I->AssociatedIrp.SystemBuffer = address;
ioStackLocation->Parameters.QueryFile.Length =??
sizeof(FILE_STANDARD_INFORMATION);
ioStackLocation->Parameters.QueryFile.FileInformationClass =??
FileStandardInformation;

IoSetCompletionRoutine(I, IoCompletion, NULL, TRUE, TRUE, TRUE);
??
// Start working around FASTFAT bug
pFCB = (PFSRTL_COMMON_FCB_HEADER)pFile->FsContext;
ExAcquireResourceExclusiveLite(pFCB->MainResource,TRUE);
// …
??
ntStatus = IoCallDriver(pFSD, I);
if (ntStatus == STATUS_PENDING)
? KeWaitForSingleObject(pEvent,Executive,KernelMode,TRUE,NULL);

// End working around
ExReleaseResourceForThreadLite(pFCB->MainResource,
? ExGetCurrentResourceThread());
// …

Regards,
Max</mailto:xxxxx>

It looks like FASTFAT can’t handle these queries being posted. If the file object is synchronous (FileObject->Flags FO_SYNCHRONOUS_IO set) it won’t try to post the request anyway. If your file object doesn’t have this flag set, why don’t you OR in the flag IRP_SYNCHRONOUS_API into pIrp->Flags of the IRP you build. This will force the IRP to be handled synchronously, which will avoid the FASTFAT bug. If you inspect an IRP issued on an asynchronous file object, you will probably see this flag being set by the IO manager.

By the way, it’s a bad idea to set the Flags field of an IRP to zero. The system could use these flags to determine where the irp came from (pool, or a lookaside list).

Nathan Tamblin

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: 14 June 2000 22:44
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

This problem cannot have anything to do with his completion routine because
this check occurs early in the completion sequence (that is, before his
completion routine has been called.) It is one of the standard checks in
IoCompleteRequest that is done to ensure the IRP has been properly set for
this case.

In reviewing the code through FAT that handles this, I note that FAT already
traps many cases where the status is STATUS_PENDING (oplocks, notably.) The
question is “what path is it walking through FAT that generates this case”.
Your stack trace indicates you are asking for type 0x5
(FileStandardInformation.)

If you trace FatCommonQueryInformation, you can see that it tracks the
“Status” of the IRP and sets it when it completes the IRP.
FatCompleteRequest_Real does nothing more than set the value of the Status
that is passed into it.

Note that FatQueryStandardInfo doesn’t return a value, nor does it affect
this Status. Thus, the only place this could be set is in
FatCommonQueryInformation. In scanning through this code, I looked at each
place where Status was set to something different and found the following:

try_return( Status = FatFsdPostRequest( IrpContext, Irp
));

Thus, this transfers control to the “finally” block where the IRP is
completed. Thus, my guess is that FAT is posting the request (which returns
STATUS_PENDING) because it cannot obtain the FCB lock on this file.

In turn, this is NOT triggering the “AbnormalTermination” routine’s logic,
so the IRP is being completed.

You can confirm this by looking at the output buffer. If the output buffer
has NOT been filled in, then you know it didn’t call the standard
information routine (in which case it must have gone down the post path.)

I hope this helps.

Regards,

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

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, June 14, 2000 5:03 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

Can we see your completion routine?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
Sent: Wednesday, June 14, 2000 1:39 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

Here’s my QmGetOpenFileInformation function, in case it helps:

NTSTATUS QmGetOpenFileInformation(PFILE_OBJECT pFile, PDEVICE_OBJECT
pVolDev, FILE_INFORMATION_CLASS InfoClass, void pBuffer, int nBufferLength)
{
KEVENT event;
IO_STATUS_BLOCK stat;
PIRP pIrp;
PIO_STACK_LOCATION pStack;
NTSTATUS ntRet;

try
{
try
{
//initialize <file:> event to signal completion
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

//allocate <file:> a new irp
pIrp = IoAllocateIrp(pVolDev->StackSize, FALSE);

//set <file:> a completion routine to free the irp
IoSetCompletionRoutine(pIrp, QmDefaultComplete, 0, TRUE, TRUE, TRUE);

//setup <file:> the irp
pIrp->UserEvent = &event;
pIrp->AssociatedIrp.SystemBuffer = pBuffer;
pIrp->UserIosb = &stat;
pIrp->Tail.Overlay.Thread = KeGetCurrentThread();
pIrp->Tail.Overlay.OriginalFileObject = pFile;
pIrp->RequestorMode = KernelMode;
pIrp->Flags = 0;

//Set <file:> up the I/O stack location.
pStack = IoGetNextIrpStackLocation(pIrp);
pStack->MajorFunction = IRP_MJ_QUERY_INFORMATION;
pStack->DeviceObject = pVolDev;
pStack->FileObject = pFile;
pStack->Parameters.QueryFile.Length = nBufferLength;
pStack->Parameters.QueryFile.FileInformationClass = InfoClass;

//Send <file:> it to the FSD
IoCallDriver(pVolDev, pIrp);
KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, NULL);

ntRet = stat.Status;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
DEFAULT_EXCEPTION_HANDLER(“QmGetOpenFileInformation”);
ntRet = GetExceptionCode();
}
}
__finally
{

}

file://report <file:> the result
return ntRet;
}

-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
Sent: Wednesday, June 14, 2000 4:36 PM
To: File Systems Developers
Subject: [ntfsd] very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
finally run it on Win2k, and immediately I started having problems. The
most persistent problem is an intermittent ASSERT from the io manager which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.

First, let me explain an assumption I made long ago: I assumed that
in the dispatch handler for an IRP_MJ_CREATE request, it would be ok for me
to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)
{
-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back through
me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking out
Win2K (note is seemed to work fine on NT4). Am I doing something completely
stupid here?

Anyways, most of the time, everything works fine in Win2K.
However, sometimes I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle for
a few seconds. It seems to occur most often as the system is unloading some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
*** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
***Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
***Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit
> kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)
ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffbc09870c ffffffffbfe787c2 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])

ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0, 0x00000005,
0xBC0987EC, 0x00000018) (EBP)

**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to the
file system driver. Here I query for FileStandardInformation.

ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)

*jts - here, I call a function which adds a record to a RtlGenericTable for
the file (the record includes the file’s full name, its size, possibly its
owner (if the file already exists). I’ve acquired a kernel mutext in the
dispatch routine to synchronize access to the table. Also in this function,
I call ZwCreateFile to attempt to open the target of the original open.

ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
jts - QmCreate is my create dispatch routine. If certain conditions are
met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and then
calling a function (NcAddFileToCacheInCreateDispatch - see above).

ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO: [0,0,3])

ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO: [11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2
NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c (EBP)

000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit
> kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4 FASTFAT!FatDeleteIrpContext_Real+0x28
(EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit
> kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction (FPO:
[1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffed43fce0 ffffffffbfe966a6 FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel

—
You are currently subscribed to ntfsd as: Nathan.Tamblin@ca.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)</file:></file:></file:></file:></file:></file:></file:></http:>

I had a similar experience when trying to read from a freshly opened file
under FASTFAT. NTFS had no problem. The problem appeared to be related to
the initiation of caching.

I needed to read a file header after the file was opened. My solution was to
set the IRP_NO_CACHE flag. It appreared that FASTFAT did not gracefully
handle me initiating caching in my create routine. Once I set the NO_CACHE
flag, everything worked OK.

Looks like we all have found various methods of working around this issue.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Tamblin, Nathan
Sent: Thursday, June 15, 2000 8:38 AM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

It looks like FASTFAT can’t handle these queries being posted.
If the file object is synchronous (FileObject->Flags
FO_SYNCHRONOUS_IO set) it won’t try to post the request anyway.
If your file object doesn’t have this flag set, why don’t you OR
in the flag IRP_SYNCHRONOUS_API into pIrp->Flags of the IRP you
build. This will force the IRP to be handled synchronously,
which will avoid the FASTFAT bug. If you inspect an IRP issued
on an asynchronous file object, you will probably see this flag
being set by the IO manager.

By the way, it’s a bad idea to set the Flags field of an IRP to
zero. The system could use these flags to determine where the
irp came from (pool, or a lookaside list).

Nathan Tamblin

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: 14 June 2000 22:44
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

This problem cannot have anything to do with his completion
routine because
this check occurs early in the completion sequence (that is, before his
completion routine has been called.) It is one of the standard checks in
IoCompleteRequest that is done to ensure the IRP has been properly set for
this case.

In reviewing the code through FAT that handles this, I note that
FAT already
traps many cases where the status is STATUS_PENDING (oplocks,
notably.) The
question is “what path is it walking through FAT that generates
this case”.
Your stack trace indicates you are asking for type 0x5
(FileStandardInformation.)

If you trace FatCommonQueryInformation, you can see that it tracks the
“Status” of the IRP and sets it when it completes the IRP.
FatCompleteRequest_Real does nothing more than set the value of the Status
that is passed into it.

Note that FatQueryStandardInfo doesn’t return a value, nor does it affect
this Status. Thus, the only place this could be set is in
FatCommonQueryInformation. In scanning through this code, I
looked at each
place where Status was set to something different and found the following:

try_return( Status =
FsdPostRequest(
IrpContext, Irp
));

Thus, this transfers control to the “finally” block where the IRP is
completed. Thus, my guess is that FAT is posting the request
(which returns
STATUS_PENDING) because it cannot obtain the FCB lock on this file.

In turn, this is NOT triggering the “AbnormalTermination” routine’s logic,
so the IRP is being completed.

You can confirm this by looking at the output buffer. If the
output buffer
has NOT been filled in, then you know it didn’t call the standard
information routine (in which case it must have gone down the post path.)

I hope this helps.

Regards,

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:
>
>
> -----Original Message-----
> From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
> Sent: Wednesday, June 14, 2000 5:03 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: very stuck with a bug - very long and in
volved
>
>
>
> Can we see your completion routine?
>
> Jamey
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
> Sent: Wednesday, June 14, 2000 1:39 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: very stuck with a bug - very long and involved
>
>
> Here’s my QmGetOpenFileInformation function, in case it helps:
>
> NTSTATUS QmGetOpenFileInformation(PFILE_OBJECT pFile, PDEVICE_OBJECT
> pVolDev, FILE_INFORMATION_CLASS InfoClass, void pBuffer, int
> nBufferLength)
> {
> KEVENT event;
> IO_STATUS_BLOCK stat;
> PIRP pIrp;
> PIO_STACK_LOCATION pStack;
> NTSTATUS ntRet;
>
> try
> {
> try
> {
> //initialize <file:> event to signal completion
> KeInitializeEvent(&event, SynchronizationEvent, FALSE);
>
> //allocate <file:> a new irp
> pIrp = IoAllocateIrp(pVolDev->StackSize, FALSE);
>
> //set <file:> a completion routine to free the irp
> IoSetCompletionRoutine(pIrp, QmDefaultComplete, 0, TRUE, TRUE, TRUE);
>
> //setup <file:> the irp
> pIrp->UserEvent = &event;
> pIrp->AssociatedIrp.SystemBuffer = pBuffer;
> pIrp->UserIosb = &stat;
> pIrp->Tail.Overlay.Thread = KeGetCurrentThread();
> pIrp->Tail.Overlay.OriginalFileObject = pFile;
> pIrp->RequestorMode = KernelMode;
> pIrp->Flags = 0;
>
> //Set <file:> up the I/O stack location.
> pStack = IoGetNextIrpStackLocation(pIrp);
> pStack->MajorFunction = IRP_MJ_QUERY_INFORMATION;
> pStack->DeviceObject = pVolDev;
> pStack->FileObject = pFile;
> pStack->Parameters.QueryFile.Length = nBufferLength;
> pStack->Parameters.QueryFile.FileInformationClass = InfoClass;
>
> //Send <file:> it to the FSD
> IoCallDriver(pVolDev, pIrp);
> KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, NULL);
>
> ntRet = stat.Status;
> }
> __except(EXCEPTION_EXECUTE_HANDLER)
> {
> DEFAULT_EXCEPTION_HANDLER(“QmGetOpenFileInformation”);
> ntRet = GetExceptionCode();
> }
> }
>__finally
> {
>
> }
>
> file://report <file:> the result
> return ntRet;
> }
>
> -----Original Message-----
> From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
> Sent: Wednesday, June 14, 2000 4:36 PM
> To: File Systems Developers
> Subject: [ntfsd] very stuck with a bug - very long and involved
>
>
>
> Hello,
> I’ve been working on a file system filter. The filter has been
> running fairly well under NT4. However, the other day, I decided to
> finally run it on Win2k, and immediately I started having problems. The
> most persistent problem is an intermittent ASSERT from the io
> manager which
> quickly resolved into a system bugcheck. It looks (to my inexperienced
> eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
> competing the IRP again from a system worker thread. I suspect my filter
> driver is the cause of this errant behavior, but I don’t know what I am
> doing wrong.
>
> First, let me explain an assumption I made long ago: I
> assumed that
> in the dispatch handler for an IRP_MJ_CREATE request, it would be
> ok for me
> to try to open the target of the create in the dispatch handler:
>
> CreateDispatchHandler(dev, irp)
>

> -if certain access rights have been requested:
>
> -figure out the targe file name
>
> --ZwCreate(TargetFileName) (recurses back through
> me, but, because of access requested, I just pass it through)
>
>
> -if the file already exists (open succeeded)
>
> -reference the handle
>
> -query the fsd for information on
> this file
>
> -derefererence file
>
> -close handle
>
> -pass IRP through to file system
> }
>
> It seems to be this recursive create behavior which is
> freaking out
> Win2K (note is seemed to work fine on NT4). Am I doing something
> completely
> stupid here?
>
> Anyways, most of the time, everything works fine in Win2K.
> However, sometimes I get an assertion, and then a crash. Most of the
> time, the assertion happends right after logon, if the system
> sits idle for
> a few seconds. It seems to occur most often as the system is
> unloading some
> other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
> annotated the stack dump with jts comments:
>
> 440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
> 'swmidi: Entering PnpDriverUnload
>*** Unloaded driver (swmidi)
> Module Unload: SWMIDI.SYS
> ***Unloaded driver (DMusic)
> Module Unload: DMUSIC.SYS
> Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)
>
> Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
> ***Source File: D:\nt\private\ntos\io\iosubs.c, line 3297
>
> >
> Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
> Execute ‘!cxr BC098390’ to dump context
> Hard coded breakpoint hit
> > kv
> ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
> ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
> ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)
> ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
> (EBP)
> ffffffffbc09870c ffffffffbfe787c2
> FASTFAT!FatCommonQueryInformation+0x2a0
> (EBP)
> ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
> (EBP)
> ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f
> (FPO: [0,0,3])
>
> ffffffffbc0987c0 ffffffffed289020
> QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0,
> 0x00000005,
> 0xBC0987EC, 0x00000018) (EBP)
>
>**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to the
> file system driver. Here I query for FileStandardInformation.
>
> ffffffffbc09886c ffffffffed288872
> QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
> 0xBC098894) (EBP)
>
> **jts - here, I call a function which adds a record to a
> RtlGenericTable for
> the file (the record includes the file’s full name, its size, possibly its
> owner (if the file already exists). I’ve acquired a kernel mutext in the
> dispatch routine to synchronize access to the table. Also in
> this function,
> I call ZwCreateFile to attempt to open the target of the original open.
>
> ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
> 0x81402548) (EBP)
>**jts - QmCreate is my create dispatch routine. If certain conditions are
> met (certain access rights are requested) I try to ascertain some
> information about the file. I do this by acquiring a kernel
> mutex and then
> calling a function (NcAddFileToCacheInCreateDispatch - see above).
>
> ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f
> (FPO: [0,0,3])
>
> ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
> ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
> ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
> ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
> ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
> ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
> TrapFrame @ bc098d64)
> 000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO:
> [11,0,0])
> 000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
> 000000000573f640 0000000075c00050
> NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
> 000000000573f650 0000000075c068eb
> NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
> 000000000573f6a4 0000000075c009f2
> NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@P
> BD@Z+0x31
> (EBP)
> 000000000573f6bc 0000000075bfe06f
> NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordTy
> pe@@@Z+0x2
> 2 (EBP)
> 000000000573f904 0000000075bfdf77
> NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
> 000000000573f90c 0000000075bfa23d
> NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
> 000000000573f91c 0000000075bb0856
> NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
> 000000000573f9e0 0000000075b7db04
> NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
> 000000000573ff84 0000000075b743ed
> NTMSSVC!?LmInitialize@@YGKXZ+0x11c (EBP)
>
> 000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
> (EBP)
> 000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)
>
>
> If I ignore this assertion, I get a second assertion:
>
> Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
> Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986
>
> >
> Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
> Execute ‘!cxr ED43F974’ to dump context
> Hard coded breakpoint hit
> > kv
> ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
> ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
> ffffffffed43fc64 ffffffffbfe731c4 FASTFAT!FatDeleteIrpContext_Real+0x28
> (EBP)
> ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
> (EBP)
> ffffffffed43fce0 ffffffffbfe966a6
> FASTFAT!FatCommonQueryInformation+0x2a0
> (EBP)
> ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
> ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
> ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
> 0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)
>
> If I ignore this assertion, I get a bugcheck:
>
> *** Fatal System Error: 0x00000044
> (0x81402288,0x00000CCA,0x00000000,0x00000000)
>
> Hard coded breakpoint hit
> > kv
> ffffffffed43f878 ffffffff80438523
> NT!RtlpBreakWithStatusInstruction (FPO:
> [1,0,0])
> ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
> ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
> ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)
> ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
> (EBP)
> ffffffffed43fce0 ffffffffbfe966a6
> FASTFAT!FatCommonQueryInformation+0x2a0
> (EBP)
> ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
> ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
> ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)
> 0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)
>
> I figure somehow I’ve bolloxed up the file system driver.
> Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
> wrong. I’m hoping its glaringly obvious to one of you, and you
> can save me
> a lot of time by telling me just what I’ve done wrong!
>
> Thanks,
> Joel
>
>
>
>
>
> —
> You are currently subscribed to ntfsd as: Nathan.Tamblin@ca.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
></file:></file:></file:></file:></file:></file:></file:></http:>

Nathan has derived the safest workaround and Tony also correctly noted
the bug (the fix is equally trivial). We first discovered this in the
filesystem plugfests just before Windows 2000 RTM.

Please, no one implement/ship the one that pre-acquires the resource.
This will not be correct for general filesystems.

As Nathan notes, if the fileobject is synchronous there is no problem -
and this is how the error escaped detection for 6-7 years. Essentially
nothing uses asynch device objects on the query path. We will address
the issue, but working around this bug should not be neccesary for the
vast majority of you. For those that still think it has to be - this is
almost certainly coming off of a fileobject you own, please just use a
synchronous one for the IRP.

Thanks.

-----Original Message-----
From: Tamblin, Nathan [mailto:Nathan.Tamblin@ca.com]
Sent: Thursday, June 15, 2000 8:38 AM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

It looks like FASTFAT can’t handle these queries being posted. If the
file object is synchronous (FileObject->Flags FO_SYNCHRONOUS_IO set) it
won’t try to post the request anyway. If your file object doesn’t have
this flag set, why don’t you OR in the flag IRP_SYNCHRONOUS_API into
pIrp->Flags of the IRP you build. This will force the IRP to be handled
synchronously, which will avoid the FASTFAT bug. If you inspect an IRP
issued on an asynchronous file object, you will probably see this flag
being set by the IO manager.

By the way, it’s a bad idea to set the Flags field of an IRP to zero.
The system could use these flags to determine where the irp came from
(pool, or a lookaside list).

Nathan Tamblin

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: 14 June 2000 22:44
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

This problem cannot have anything to do with his completion routine
because
this check occurs early in the completion sequence (that is, before his
completion routine has been called.) It is one of the standard checks
in
IoCompleteRequest that is done to ensure the IRP has been properly set
for
this case.

In reviewing the code through FAT that handles this, I note that FAT
already
traps many cases where the status is STATUS_PENDING (oplocks, notably.)
The
question is “what path is it walking through FAT that generates this
case”.
Your stack trace indicates you are asking for type 0x5
(FileStandardInformation.)

If you trace FatCommonQueryInformation, you can see that it tracks the
“Status” of the IRP and sets it when it completes the IRP.
FatCompleteRequest_Real does nothing more than set the value of the
Status
that is passed into it.

Note that FatQueryStandardInfo doesn’t return a value, nor does it
affect
this Status. Thus, the only place this could be set is in
FatCommonQueryInformation. In scanning through this code, I looked at
each
place where Status was set to something different and found the
following:

try_return( Status = FatFsdPostRequest( IrpContext,
Irp
));

Thus, this transfers control to the “finally” block where the IRP is
completed. Thus, my guess is that FAT is posting the request (which
returns
STATUS_PENDING) because it cannot obtain the FCB lock on this file.

In turn, this is NOT triggering the “AbnormalTermination” routine’s
logic,
so the IRP is being completed.

You can confirm this by looking at the output buffer. If the output
buffer
has NOT been filled in, then you know it didn’t call the standard
information routine (in which case it must have gone down the post
path.)

I hope this helps.

Regards,

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

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, June 14, 2000 5:03 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

Can we see your completion routine?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
Sent: Wednesday, June 14, 2000 1:39 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

Here’s my QmGetOpenFileInformation function, in case it helps:

NTSTATUS QmGetOpenFileInformation(PFILE_OBJECT pFile, PDEVICE_OBJECT
pVolDev, FILE_INFORMATION_CLASS InfoClass, void pBuffer, int
nBufferLength)
{
KEVENT event;
IO_STATUS_BLOCK stat;
PIRP pIrp;
PIO_STACK_LOCATION pStack;
NTSTATUS ntRet;

try
{
try
{
//initialize <file:> event to signal completion
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

//allocate <file:> a new irp
pIrp = IoAllocateIrp(pVolDev->StackSize, FALSE);

//set <file:> a completion routine to free the irp
IoSetCompletionRoutine(pIrp, QmDefaultComplete, 0, TRUE, TRUE, TRUE);

//setup <file:> the irp
pIrp->UserEvent = &event;
pIrp->AssociatedIrp.SystemBuffer = pBuffer;
pIrp->UserIosb = &stat;
pIrp->Tail.Overlay.Thread = KeGetCurrentThread();
pIrp->Tail.Overlay.OriginalFileObject = pFile;
pIrp->RequestorMode = KernelMode;
pIrp->Flags = 0;

//Set <file:> up the I/O stack location.
pStack = IoGetNextIrpStackLocation(pIrp);
pStack->MajorFunction = IRP_MJ_QUERY_INFORMATION;
pStack->DeviceObject = pVolDev;
pStack->FileObject = pFile;
pStack->Parameters.QueryFile.Length = nBufferLength;
pStack->Parameters.QueryFile.FileInformationClass = InfoClass;

//Send <file:> it to the FSD
IoCallDriver(pVolDev, pIrp);
KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, NULL);

ntRet = stat.Status;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
DEFAULT_EXCEPTION_HANDLER(“QmGetOpenFileInformation”);
ntRet = GetExceptionCode();
}
}
__finally
{

}

file://report <file:> the result
return ntRet;
}

-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
Sent: Wednesday, June 14, 2000 4:36 PM
To: File Systems Developers
Subject: [ntfsd] very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
finally run it on Win2k, and immediately I started having problems.
The
most persistent problem is an intermittent ASSERT from the io manager
which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my
filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.

First, let me explain an assumption I made long ago: I assumed
that
in the dispatch handler for an IRP_MJ_CREATE request, it would be ok for
me
to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)
{
-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back
through
me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this
file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking
out
Win2K (note is seemed to work fine on NT4). Am I doing something
completely
stupid here?

Anyways, most of the time, everything works fine in Win2K.
However, sometimes I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle
for
a few seconds. It seems to occur most often as the system is unloading
some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
*** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
***Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
***Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit
> kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)

ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffbc09870c ffffffffbfe787c2
FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO:
[0,0,3])

ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0,
0x00000005,
0xBC0987EC, 0x00000018) (EBP)

**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to
the
file system driver. Here I query for FileStandardInformation.

ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)

*jts - here, I call a function which adds a record to a RtlGenericTable
for
the file (the record includes the file’s full name, its size, possibly
its
owner (if the file already exists). I’ve acquired a kernel mutext in
the
dispatch routine to synchronize access to the table. Also in this
function,
I call ZwCreateFile to attempt to open the target of the original open.

ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
jts - QmCreate is my create dispatch routine. If certain conditions
are
met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and
then
calling a function (NcAddFileToCacheInCreateDispatch - see above).

ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO:
[0,0,3])

ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]
TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO:
[11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2
NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0
x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z
+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c
(EBP)

000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit
> kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4
FASTFAT!FatDeleteIrpContext_Real+0x28
(EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38
(EBP)
ffffffffed43fce0 ffffffffbfe966a6
FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)

0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit
> kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction
(FPO:
[1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)

ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64
(EBP)
ffffffffed43fce0 ffffffffbfe966a6
FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)

0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save
me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel

—
You are currently subscribed to ntfsd as: Nathan.Tamblin@ca.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

—
You are currently subscribed to ntfsd as: xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)</file:></file:></file:></file:></file:></file:></file:></http:>

Of course, I meant to say “Essentially nothing uses asynch file objects
on the query path”.

Thanks.

-----Original Message-----
From: Daniel Lovinger
Sent: Thursday, June 15, 2000 1:53 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

Nathan has derived the safest workaround and Tony also correctly noted
the bug (the fix is equally trivial). We first discovered this in the
filesystem plugfests just before Windows 2000 RTM.

Please, no one implement/ship the one that pre-acquires the resource.
This will not be correct for general filesystems.

As Nathan notes, if the fileobject is synchronous there is no problem -
and this is how the error escaped detection for 6-7 years. Essentially
nothing uses asynch device objects on the query path. We will address
the issue, but working around this bug should not be neccesary for the
vast majority of you. For those that still think it has to be - this is
almost certainly coming off of a fileobject you own, please just use a
synchronous one for the IRP.

Thanks.

-----Original Message-----
From: Tamblin, Nathan [ mailto:Nathan.Tamblin@ca.com
mailto:nathan.tamblin ]
Sent: Thursday, June 15, 2000 8:38 AM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

It looks like FASTFAT can’t handle these queries being posted. If the
file object is synchronous (FileObject->Flags FO_SYNCHRONOUS_IO set) it
won’t try to post the request anyway. If your file object doesn’t have
this flag set, why don’t you OR in the flag IRP_SYNCHRONOUS_API into
pIrp->Flags of the IRP you build. This will force the IRP to be handled
synchronously, which will avoid the FASTFAT bug. If you inspect an IRP
issued on an asynchronous file object, you will probably see this flag
being set by the IO manager.

By the way, it’s a bad idea to set the Flags field of an IRP to zero.
The system could use these flags to determine where the irp came from
(pool, or a lookaside list).

Nathan Tamblin

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com mailto:xxxxx]
Sent: 14 June 2000 22:44
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

This problem cannot have anything to do with his completion routine
because
this check occurs early in the completion sequence (that is, before his
completion routine has been called.) It is one of the standard checks
in
IoCompleteRequest that is done to ensure the IRP has been properly set
for
this case.

In reviewing the code through FAT that handles this, I note that FAT
already
traps many cases where the status is STATUS_PENDING (oplocks, notably.)
The
question is “what path is it walking through FAT that generates this
case”.
Your stack trace indicates you are asking for type 0x5
(FileStandardInformation.)

If you trace FatCommonQueryInformation, you can see that it tracks the
“Status” of the IRP and sets it when it completes the IRP.
FatCompleteRequest_Real does nothing more than set the value of the
Status
that is passed into it.

Note that FatQueryStandardInfo doesn’t return a value, nor does it
affect
this Status. Thus, the only place this could be set is in
FatCommonQueryInformation. In scanning through this code, I looked at
each
place where Status was set to something different and found the
following:

try_return( Status = FatFsdPostRequest( IrpContext,
Irp
));

Thus, this transfers control to the “finally” block where the IRP is
completed. Thus, my guess is that FAT is posting the request (which
returns
STATUS_PENDING) because it cannot obtain the FCB lock on this file.

In turn, this is NOT triggering the “AbnormalTermination” routine’s
logic,
so the IRP is being completed.

You can confirm this by looking at the output buffer. If the output
buffer
has NOT been filled in, then you know it didn’t call the standard
information routine (in which case it must have gone down the post
path.)

I hope this helps.

Regards,

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

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com
mailto:xxxxx]
Sent: Wednesday, June 14, 2000 5:03 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

Can we see your completion routine?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com
mailto:xxxxx]On Behalf Of Smith, Joel
Sent: Wednesday, June 14, 2000 1:39 PM
To: File Systems Developers
Subject: [ntfsd] RE: very stuck with a bug - very long and involved

Here’s my QmGetOpenFileInformation function, in case it helps:

NTSTATUS QmGetOpenFileInformation(PFILE_OBJECT pFile, PDEVICE_OBJECT
pVolDev, FILE_INFORMATION_CLASS InfoClass, void pBuffer, int
nBufferLength)
{
KEVENT event;
IO_STATUS_BLOCK stat;
PIRP pIrp;
PIO_STACK_LOCATION pStack;
NTSTATUS ntRet;

try
{
try
{
//initialize < file://initialize <file:> > event to
signal completion
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

//allocate < file://allocate <file:> > a new irp
pIrp = IoAllocateIrp(pVolDev->StackSize, FALSE);

//set < file://set <file:> > a completion routine to free the
irp
IoSetCompletionRoutine(pIrp, QmDefaultComplete, 0, TRUE, TRUE, TRUE);

//setup < file://setup <file:> > the irp
pIrp->UserEvent = &event;
pIrp->AssociatedIrp.SystemBuffer = pBuffer;
pIrp->UserIosb = &stat;
pIrp->Tail.Overlay.Thread = KeGetCurrentThread();
pIrp->Tail.Overlay.OriginalFileObject = pFile;
pIrp->RequestorMode = KernelMode;
pIrp->Flags = 0;

//Set < file://Set <file:> > up the I/O stack location.
pStack = IoGetNextIrpStackLocation(pIrp);
pStack->MajorFunction = IRP_MJ_QUERY_INFORMATION;
pStack->DeviceObject = pVolDev;
pStack->FileObject = pFile;
pStack->Parameters.QueryFile.Length = nBufferLength;
pStack->Parameters.QueryFile.FileInformationClass = InfoClass;

//Send < file://Send <file:> > it to the FSD
IoCallDriver(pVolDev, pIrp);
KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, NULL);

ntRet = stat.Status;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
DEFAULT_EXCEPTION_HANDLER(“QmGetOpenFileInformation”);
ntRet = GetExceptionCode();
}
}
__finally
{

}

file://report <file:> < file://report <file:> >
the result
return ntRet;
}

-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com
mailto:xxxxx]
Sent: Wednesday, June 14, 2000 4:36 PM
To: File Systems Developers
Subject: [ntfsd] very stuck with a bug - very long and involved

Hello,
I’ve been working on a file system filter. The filter has been
running fairly well under NT4. However, the other day, I decided to
finally run it on Win2k, and immediately I started having problems.
The
most persistent problem is an intermittent ASSERT from the io manager
which
quickly resolved into a system bugcheck. It looks (to my inexperienced
eyes) that FASTFAT is completing an IRP with STATUS_PENDING and then
competing the IRP again from a system worker thread. I suspect my
filter
driver is the cause of this errant behavior, but I don’t know what I am
doing wrong.

First, let me explain an assumption I made long ago: I assumed
that
in the dispatch handler for an IRP_MJ_CREATE request, it would be ok for
me
to try to open the target of the create in the dispatch handler:

CreateDispatchHandler(dev, irp)
{
-if certain access rights have been requested:

-figure out the targe file name

–ZwCreate(TargetFileName) (recurses back
through
me, but, because of access requested, I just pass it through)

-if the file already exists (open succeeded)

-reference the handle

-query the fsd for information on this
file

-derefererence file

-close handle

-pass IRP through to file system
}

It seems to be this recursive create behavior which is freaking
out
Win2K (note is seemed to work fine on NT4). Am I doing something
completely
stupid here?

Anyways, most of the time, everything works fine in Win2K.
However, sometimes I get an assertion, and then a crash. Most of the
time, the assertion happends right after logon, if the system sits idle
for
a few seconds. It seems to occur most often as the system is unloading
some
other drivers. Here is the ASSERTION followed by a stack dump ( I’ve
annotated the stack dump with jts comments:

440.600p> Cairole: Unbalanced call to CoInitialize for thread 600
'swmidi: Entering PnpDriverUnload
*** Unloaded driver (swmidi)
Module Unload: SWMIDI.SYS
***Unloaded driver (DMusic)
Module Unload: DMUSIC.SYS
Module Load: C:\WINNT\system32\NTMSDBA.DLL (symbol loading deferred)

Assertion failed: Irp->IoStatus.Status != STATUS_PENDING
***Source File: D:\nt\private\ntos\io\iosubs.c, line 3297

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr BC098390’ to dump context
Hard coded breakpoint hit
> kv
ffffffffbc098384 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffbc098660 ffffffff804249cb NT!RtlAssert+0x9a (EBP)
ffffffffbc098694 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x85 (EBP)

ffffffffbc0986a0 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64

(EBP)
ffffffffbc09870c ffffffffbfe787c2
FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffbc098750 ffffffff80424606 FASTFAT!FatFsdQueryInformation+0x5a
(EBP)
ffffffffbc098768 ffffffffed28a1bf NT!@IopfCallDriver@8+0x4f (FPO:
[0,0,3])

ffffffffbc0987c0 ffffffffed289020
QMFILTER!QmGetOpenFileInformation+0x163(0x81437748, 0x818546A0,
0x00000005,
0xBC0987EC, 0x00000018) (EBP)

**jts - QmGetOpenFileInformation sends an IRP_MJ_QUERY_INFORMATION to
the
file system driver. Here I query for FileStandardInformation.

ffffffffbc09886c ffffffffed288872
QMFILTER!NcAddFileToCacheInCreateDispatch+0x246(0x81853C00, 0x81402548,
0xBC098894) (EBP)

*jts - here, I call a function which adds a record to a RtlGenericTable
for
the file (the record includes the file’s full name, its size, possibly
its
owner (if the file already exists). I’ve acquired a kernel mutext in
the
dispatch routine to synchronize access to the table. Also in this
function,
I call ZwCreateFile to attempt to open the target of the original open.

ffffffffbc0988f4 ffffffff80424606 QMFILTER!QmCreate+0x145(0x81853C00,
0x81402548) (EBP)
jts - QmCreate is my create dispatch routine. If certain conditions
are
met (certain access rights are requested) I try to ascertain some
information about the file. I do this by acquiring a kernel mutex and
then
calling a function (NcAddFileToCacheInCreateDispatch - see above).

ffffffffbc09890c ffffffff8054106f NT!@IopfCallDriver@8+0x4f (FPO:
[0,0,3])

ffffffffbc098a8c ffffffff804967fe NT!IopParseDevice+0xa52 (EBP)
ffffffffbc098afc ffffffff8056ceb1 NT!ObpLookupObjectName+0x5f8 (EBP)
ffffffffbc098c0c ffffffff80510351 NT!ObOpenObjectByName+0x119 (EBP)
ffffffffbc098ce0 ffffffff8051c4b3 NT!IoCreateFile+0x425 (EBP)
ffffffffbc098d24 ffffffff804b19ba NT!NtCreateFile+0x61 (EBP)
ffffffffbc098d24 0000000077f7851b NT!KiSystemService+0x10a (FPO: [0,3]

TrapFrame @ bc098d64)
000000000573f578 0000000077e6ec35 NTDLL!ZwCreateFile+0xb (FPO:
[11,0,0])
000000000573f614 0000000075bfff2c KERNEL32!CreateFileW+0x343 (EBP)
000000000573f640 0000000075c00050
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x2a (EBP)
000000000573f650 0000000075c068eb
NTMSDBA!?xxxxx@NtmsDbFile@@UAEKK@Z+0x14 (EBP)
000000000573f6a4 0000000075c009f2
NTMSDBA!?xxxxx@NtmsDbRegistration@@QAEKAAVNtmsDbRecordType@@PBD@Z+0
x31
(EBP)
000000000573f6bc 0000000075bfe06f
NTMSDBA!?xxxxx@NtmsDatabase@@QAEKPBDAAVNtmsDbRecordType@@@Z
+0x2
2 (EBP)
000000000573f904 0000000075bfdf77
NTMSDBA!?xxxxx@NtmsDbObjTypeDef@@QAEXXZ+0x2d (EBP)
000000000573f90c 0000000075bfa23d
NTMSDBA!?xxxxx@NtmsDbDataCtxt@@IAEXXZ+0x19 (FPO: [0,0,1])
000000000573f91c 0000000075bb0856
NTMSDBA!??0NtmsDbDataCtxt@@xxxxx@PBD0H@Z+0x2d (EBP)
000000000573f9e0 0000000075b7db04
NTMSSVC!?LmConfigure@@YGKPAGAAJPAVDeviceInfo@@@Z+0x22 (EBP)
000000000573ff84 0000000075b743ed NTMSSVC!?LmInitialize@@YGKXZ+0x11c
(EBP)

000000000573ffb4 0000000077e5d4a3 NTMSSVC!?LmInitStart@@YGKPAX@Z+0x4f
(EBP)
000000000573ffec 0000000000000000 KERNEL32!BaseThreadStart+0x52 (EBP)

If I ignore this assertion, I get a second assertion:

Assertion failed: IrpContext->NodeTypeCode == FAT_NTC_IRP_CONTEXT
Source File: D:\nt\private\ntos\fastfat\strucsup.c, line 1986

>
Break, Ignore, Terminate Process or Terminate Thread (bipt)? b
Execute ‘!cxr ED43F974’ to dump context
Hard coded breakpoint hit
> kv
ffffffffed43f968 ffffffff804a35df NT!DbgBreakPoint (FPO: [0,0,0])
ffffffffed43fc44 ffffffffbfe71f9c NT!RtlAssert+0x9a (EBP)
ffffffffed43fc64 ffffffffbfe731c4
FASTFAT!FatDeleteIrpContext_Real+0x28
(EBP)
ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x38

(EBP)
ffffffffed43fce0 ffffffffbfe966a6
FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)

0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

If I ignore this assertion, I get a bugcheck:

Fatal System Error: 0x00000044
(0x81402288,0x00000CCA,0x00000000,0x00000000)

Hard coded breakpoint hit
> kv
ffffffffed43f878 ffffffff80438523 NT!RtlpBreakWithStatusInstruction
(FPO:
[1,0,0])
ffffffffed43f8a8 ffffffff80438b01 NT!KiBugCheckDebugBreak+0x31 (EBP)
ffffffffed43fc30 ffffffff80424978 NT!KeBugCheckEx+0x37b (EBP)
ffffffffed43fc68 ffffffffbfe731f0 NT!@IopfCompleteRequest@8+0x32 (EBP)

ffffffffed43fc74 ffffffffbfe78b4c FASTFAT!FatCompleteRequest_Real+0x64

(EBP)
ffffffffed43fce0 ffffffffbfe966a6
FASTFAT!FatCommonQueryInformation+0x2a0
(EBP)
ffffffffed43fd40 ffffffff8041beae FASTFAT!FatFspDispatch+0x10b (EBP)
ffffffffed43fda8 ffffffff8049d5a2 NT!ExpWorkerThread+0x106 (EBP)
ffffffffed43fddc ffffffff804b70aa NT!PspSystemThreadStartup+0x54 (EBP)

0000000000000000 0000000000000000 NT!KiThreadStartup+0x16 (No FPO)

I figure somehow I’ve bolloxed up the file system driver.
Unfortuneately, I haven’t the skill and knowledge to see what I’ve done
wrong. I’m hoping its glaringly obvious to one of you, and you can save
me
a lot of time by telling me just what I’ve done wrong!

Thanks,
Joel

—
You are currently subscribed to ntfsd as: Nathan.Tamblin@ca.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

—
You are currently subscribed to ntfsd as: xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)</mailto:xxxxx></file:></file:></file:></file:></file:></file:></file:></file:></mailto:xxxxx></mailto:xxxxx></http:></http:></mailto:xxxxx></mailto:nathan.tamblin>

RE: [ntfsd] RE: very stuck with a bug - very long and involved>Please, no
one implement/ship the one that pre-acquires the resource. This

will not be correct for general filesystems.

What if the caller will also set TopLevelIrp to FSP_TOP_LEVEL_IRP?
Will it still be wrong? Looks like Mm does exactly this when requesting file
growth from CreateFileMapping/NtCreateSection.

Max

But this is only when the file is already preacquired by
FsRtlAcquireFileExclusive. Without pre-acquision of
FSD resources this must be considered as too dirty method.

Paul

-----P?vodn? zpr?va-----
Od: Maxim S. Shatskih [SMTP:xxxxx@storagecraft.com]
Odesl?no: 16. ?ervna 2000 17:43
Komu: File Systems Developers
P?edm?t: [ntfsd] RE: very stuck with a bug - very long and involved

RE: [ntfsd] RE: very stuck with a bug - very long and involved>Please, no
one implement/ship the one that pre-acquires the resource. This
>will not be correct for general filesystems.

What if the caller will also set TopLevelIrp to FSP_TOP_LEVEL_IRP?
Will it still be wrong? Looks like Mm does exactly this when requesting
file
growth from CreateFileMapping/NtCreateSection.

Max

---

You are currently subscribed to ntfsd as: xxxxx@sodatsw.cz
To unsubscribe send a blank email to $subst(‘Email.Unsub’)