Re: win2k crash deleting directory -- resolved!

NTFSD
1

Thanks to Neal for pointing out the problem.

The problem is in the rolling of the irp. I was
passing an event to my completion routine to signal
when completion was finished. I was passing this by
putting it into Irp->UserEvent. It is plain to me now
that this is evil. The IO Manager was signaling the
event and I would mistakenly think that my completion
had done it. The solution was to pass it in the
context field.

— Randy Cook wrote:

> Below is a !analyze -v of a crash I’m only seeing on
> win2k. This happens when I roll an irp to delete a
> directory that I’ve just created.
>
> Following the output of !analyze -v is the stack of
> the thread that actually caused the crash. At the
> end
> is the code that rolled the irp.
>
> I looked at the device object and the file object
> that
> are handed in to the function and they appear valid.
>
> Any ideas? Thanks.
>
> NTFS_FILE_SYSTEM (24)
> If you see NtfsExceptionFilter on the stack then
> the 2nd and 3rd
> parameters are the exception record and context
> record. Do a .cxr
> on the 3rd parameter and then kb to obtain a
> more
> informative stack
> trace.
> Arguments:
> Arg1: 0019025e
> Arg2: eb43bbec
> Arg3: eb43b844
> Arg4: bff63f6d
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_RECORD: eb43bbec – (.exr
> ffffffffeb43bbec)
> ExceptionAddress: bff63f6d
>
(Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x00000044)
> ExceptionCode: c0000005 (Access violation)
> ExceptionFlags: 00000000
> NumberParameters: 2
> Parameter[0]: 00000000
> Parameter[1]: 0000000c
> Attempt to read from address 0000000c
>
> CONTEXT: eb43b844 – (.cxr ffffffffeb43b844)
> eax=00000000 ebx=f581aa50 ecx=eb43bd30 edx=80010031
> esi=e1e41868 edi=eb43bd30
> eip=bff63f6d esp=eb43bcb4 ebp=eb43bcf8 iopl=0
>
> nv up ei pl zr na po nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>
> efl=00210246
> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44:
> bff63f6d ff700c push dword ptr
> [eax+0xc]
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x24
>
> LAST_CONTROL_TRANSFER: from bff50002 to bff63f6d
>
> STACK_TEXT:
> eb43bcf8 bff50002 848cb5a8 e1e41868 848cb6a8
> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44
> eb43bd78 80416bfa 848cb5a8 00000000 00000000
> Ntfs!NtfsSpecialDispatch+0xaf
> eb43bda8 80454a00 848cb5a8 00000000 00000000
> nt!ExpWorkerThread+0xae
> eb43bddc 80469212 80416b4c 00000001 00000000
> nt!PspSystemThreadStartup+0x54
> 00000000 00000000 00000000 00000000 00000000
> nt!KiThreadStartup+0x16
>
>
> MODULE_NAME: Unknown_Module
>
> IMAGE_NAME: Unknown_Image
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> STACK_COMMAND: .cxr ffffffffeb43b844 ; kb
>
> BUCKET_ID: 0x24
> *** Followup info cannot be found !!! Please
> contact
> “Debugger Team”
>
>
>
>
>
>
> f541c378 8042d3c6 bff03bc0 00000000 80416aaa
> nt!KiUnlockDispatcherDatabase+0x73
> f541c384 80416aaa 804746dc 848cb6a8 bff4ff3e
> nt!KeInsertQueue+0x22
> f541c390 bff4ff3e 848cb6a8 00000001 e1e41868
> nt!ExQueueWorkItem+0x16
> f541c3ac bff003c8 827ef9a8 f581aacc bff63f29
> Ntfs!NtfsPostSpecial+0xd2
> f541c3d8 bff64065 e1e41868 00000000 c0040037
> Ntfs!NtfsLogEvent+0xe5
> f541c3f0 bff00425 827ef9a8 f581aa50 00000001
> Ntfs!NtfsMarkVolumeDirty+0x56
> f541c408 bfef8a84 827ef9a8 c0000102 00000000
> Ntfs!NtfsPostVcbIsCorrupt+0x17
> f541c424 bff1f4f8 827ef9a8 c0000102 00000000
> Ntfs!NtfsRaiseStatus+0x31
> f541c458 bff0669b 827ef9a8 c7f53430 f541c4dc
> Ntfs!NtfsFindInFileRecord+0x166
> f541c498 bff0cffb 827ef9a8 e1f02008 c7f53490
> Ntfs!NtfsLookupInFileRecord+0x16a
> f541c524 bff117dd 827ef9a8 e1f02008 f541c548
> Ntfs!NtfsIsFileDeleteable+0x53
> f541c57c bff10dc9 827ef9a8 ffa6db48 a998ae70
> Ntfs!NtfsSetDispositionInfo+0xf3
> f541c610 bff068c3 827ef9a8 a998ae70 f581a980
> Ntfs!NtfsCommonSetInformation+0x420
> f541c680 8041dded f581a980 a998ae70 000000c9
> Ntfs!NtfsFsdSetInformation+0xbf
> f541c694 80528955 f581a980 00000000 a998ae70
> nt!IopfCallDriver+0x35
> f541c6b0 f5806ef8 00000000 00100001 f541c7c8
> nt!IovCallDriver+0x77
> f541c6e0 f58163bf f581a980 ffa6db48 00000000
> MyDriver!MyDelete+0xbe
>
>
>
>
>
> NTSTATUS MyDelete(PDEVICE_OBJECT DeviceObject,
> PFILE_OBJECT FileObject, BOOLEAN deleteFlag)
> {
> NTSTATUS status;
> KEVENT event;
> PIRP irp;
> IO_STATUS_BLOCK IoStatusBlock;
> PIO_STACK_LOCATION ioStackLocation;
> FILE_DISPOSITION_INFORMATION fileDispositionInfo;
>
> KeInitializeEvent(&event, SynchronizationEvent,
> FALSE);
>
> irp = IoAllocateIrp(DeviceObject->StackSize,
> FALSE);
> if(!irp)
> {
> return ERROR_SEVERITY_ERROR;
> }
>
> irp->AssociatedIrp.SystemBuffer =
> &fileDispositionInfo;
> irp->UserEvent = &event;
> irp->Flags = IRP_BUFFERED_IO | IRP_SYNCHRONOUS_API;
> irp->UserIosb = &IoStatusBlock;
> irp->Tail.Overlay.Thread = PsGetCurrentThread();
> irp->Tail.Overlay.OriginalFileObject = FileObject;
> //
> <– Neal says not to do this
> irp->RequestorMode = KernelMode;
>
> ioStackLocation = IoGetNextIrpStackLocation(irp);
>
> ioStackLocation->MajorFunction =
> IRP_MJ_SET_INFORMATION;
> ioStackLocation->MinorFunction = 0;
> ioStackLocation->Parameters.SetFile.Length =
> sizeof(FILE_DISPOSITION_INFORMATION);
>
>
ioStackLocation->Parameters.SetFile.FileInformationClass
> = FileDispositionInformation;
> ioStackLocation->DeviceObject = DeviceObject;
> ioStackLocation->FileObject = FileObject;
>
> fileDispositionInfo.DeleteFile = deleteFlag;
>
> IoSetCompletionRoutine(irp,
> fslxQueryDirectoryCompletionRoutine, 0, TRUE, TRUE,
> TRUE);
>
> (void) IoCallDriver(DeviceObject, irp);
>
> KeWaitForSingleObject(&event, Executive,
> KernelMode,
> TRUE, 0);
>
> status = irp->IoStatus.Status;
>
> IoFreeIrp(irp);
>
> return status;
> }
>
>
>
> —
>
=== message truncated ===

2

Randy

I cant find post where Neail pointed out the problem … I sure would like
to understand why it is evil to put pointer to event in Irp->UserEvent …

Thanks
Lyndon

“Randy Cook” wrote in message news:xxxxx@ntfsd…
> Thanks to Neal for pointing out the problem.
>
> The problem is in the rolling of the irp. I was
> passing an event to my completion routine to signal
> when completion was finished. I was passing this by
> putting it into Irp->UserEvent. It is plain to me now
> that this is evil. The IO Manager was signaling the
> event and I would mistakenly think that my completion
> had done it. The solution was to pass it in the
> context field.
>
> — Randy Cook wrote:
>
>> Below is a !analyze -v of a crash I’m only seeing on
>> win2k. This happens when I roll an irp to delete a
>> directory that I’ve just created.
>>
>> Following the output of !analyze -v is the stack of
>> the thread that actually caused the crash. At the
>> end
>> is the code that rolled the irp.
>>
>> I looked at the device object and the file object
>> that
>> are handed in to the function and they appear valid.
>>
>> Any ideas? Thanks.
>>
>> NTFS_FILE_SYSTEM (24)
>> If you see NtfsExceptionFilter on the stack then
>> the 2nd and 3rd
>> parameters are the exception record and context
>> record. Do a .cxr
>> on the 3rd parameter and then kb to obtain a
>> more
>> informative stack
>> trace.
>> Arguments:
>> Arg1: 0019025e
>> Arg2: eb43bbec
>> Arg3: eb43b844
>> Arg4: bff63f6d
>>
>> Debugging Details:
>> ------------------
>>
>>
>> EXCEPTION_RECORD: eb43bbec – (.exr
>> ffffffffeb43bbec)
>> ExceptionAddress: bff63f6d
>>
> (Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x00000044)
>> ExceptionCode: c0000005 (Access violation)
>> ExceptionFlags: 00000000
>> NumberParameters: 2
>> Parameter[0]: 00000000
>> Parameter[1]: 0000000c
>> Attempt to read from address 0000000c
>>
>> CONTEXT: eb43b844 – (.cxr ffffffffeb43b844)
>> eax=00000000 ebx=f581aa50 ecx=eb43bd30 edx=80010031
>> esi=e1e41868 edi=eb43bd30
>> eip=bff63f6d esp=eb43bcb4 ebp=eb43bcf8 iopl=0
>>
>> nv up ei pl zr na po nc
>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>>
>> efl=00210246
>> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44:
>> bff63f6d ff700c push dword ptr
>> [eax+0xc]
>> Resetting default scope
>>
>> DEFAULT_BUCKET_ID: DRIVER_FAULT
>>
>> BUGCHECK_STR: 0x24
>>
>> LAST_CONTROL_TRANSFER: from bff50002 to bff63f6d
>>
>> STACK_TEXT:
>> eb43bcf8 bff50002 848cb5a8 e1e41868 848cb6a8
>> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44
>> eb43bd78 80416bfa 848cb5a8 00000000 00000000
>> Ntfs!NtfsSpecialDispatch+0xaf
>> eb43bda8 80454a00 848cb5a8 00000000 00000000
>> nt!ExpWorkerThread+0xae
>> eb43bddc 80469212 80416b4c 00000001 00000000
>> nt!PspSystemThreadStartup+0x54
>> 00000000 00000000 00000000 00000000 00000000
>> nt!KiThreadStartup+0x16
>>
>>
>> MODULE_NAME: Unknown_Module
>>
>> IMAGE_NAME: Unknown_Image
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>>
>> STACK_COMMAND: .cxr ffffffffeb43b844 ; kb
>>
>> BUCKET_ID: 0x24
>> *** Followup info cannot be found !!! Please
>> contact
>> “Debugger Team”
>>
>>
>>
>>
>>
>>
>> f541c378 8042d3c6 bff03bc0 00000000 80416aaa
>> nt!KiUnlockDispatcherDatabase+0x73
>> f541c384 80416aaa 804746dc 848cb6a8 bff4ff3e
>> nt!KeInsertQueue+0x22
>> f541c390 bff4ff3e 848cb6a8 00000001 e1e41868
>> nt!ExQueueWorkItem+0x16
>> f541c3ac bff003c8 827ef9a8 f581aacc bff63f29
>> Ntfs!NtfsPostSpecial+0xd2
>> f541c3d8 bff64065 e1e41868 00000000 c0040037
>> Ntfs!NtfsLogEvent+0xe5
>> f541c3f0 bff00425 827ef9a8 f581aa50 00000001
>> Ntfs!NtfsMarkVolumeDirty+0x56
>> f541c408 bfef8a84 827ef9a8 c0000102 00000000
>> Ntfs!NtfsPostVcbIsCorrupt+0x17
>> f541c424 bff1f4f8 827ef9a8 c0000102 00000000
>> Ntfs!NtfsRaiseStatus+0x31
>> f541c458 bff0669b 827ef9a8 c7f53430 f541c4dc
>> Ntfs!NtfsFindInFileRecord+0x166
>> f541c498 bff0cffb 827ef9a8 e1f02008 c7f53490
>> Ntfs!NtfsLookupInFileRecord+0x16a
>> f541c524 bff117dd 827ef9a8 e1f02008 f541c548
>> Ntfs!NtfsIsFileDeleteable+0x53
>> f541c57c bff10dc9 827ef9a8 ffa6db48 a998ae70
>> Ntfs!NtfsSetDispositionInfo+0xf3
>> f541c610 bff068c3 827ef9a8 a998ae70 f581a980
>> Ntfs!NtfsCommonSetInformation+0x420
>> f541c680 8041dded f581a980 a998ae70 000000c9
>> Ntfs!NtfsFsdSetInformation+0xbf
>> f541c694 80528955 f581a980 00000000 a998ae70
>> nt!IopfCallDriver+0x35
>> f541c6b0 f5806ef8 00000000 00100001 f541c7c8
>> nt!IovCallDriver+0x77
>> f541c6e0 f58163bf f581a980 ffa6db48 00000000
>> MyDriver!MyDelete+0xbe
>>
>>
>>
>>
>>
>> NTSTATUS MyDelete(PDEVICE_OBJECT DeviceObject,
>> PFILE_OBJECT FileObject, BOOLEAN deleteFlag)
>> {
>> NTSTATUS status;
>> KEVENT event;
>> PIRP irp;
>> IO_STATUS_BLOCK IoStatusBlock;
>> PIO_STACK_LOCATION ioStackLocation;
>> FILE_DISPOSITION_INFORMATION fileDispositionInfo;
>>
>> KeInitializeEvent(&event, SynchronizationEvent,
>> FALSE);
>>
>> irp = IoAllocateIrp(DeviceObject->StackSize,
>> FALSE);
>> if(!irp)
>> {
>> return ERROR_SEVERITY_ERROR;
>> }
>>
>> irp->AssociatedIrp.SystemBuffer =
>> &fileDispositionInfo;
>> irp->UserEvent = &event;
>> irp->Flags = IRP_BUFFERED_IO | IRP_SYNCHRONOUS_API;
>> irp->UserIosb = &IoStatusBlock;
>> irp->Tail.Overlay.Thread = PsGetCurrentThread();
>> irp->Tail.Overlay.OriginalFileObject = FileObject;
>> //
>> <– Neal says not to do this
>> irp->RequestorMode = KernelMode;
>>
>> ioStackLocation = IoGetNextIrpStackLocation(irp);
>>
>> ioStackLocation->MajorFunction =
>> IRP_MJ_SET_INFORMATION;
>> ioStackLocation->MinorFunction = 0;
>> ioStackLocation->Parameters.SetFile.Length =
>> sizeof(FILE_DISPOSITION_INFORMATION);
>>
>>
> ioStackLocation->Parameters.SetFile.FileInformationClass
>> = FileDispositionInformation;
>> ioStackLocation->DeviceObject = DeviceObject;
>> ioStackLocation->FileObject = FileObject;
>>
>> fileDispositionInfo.DeleteFile = deleteFlag;
>>
>> IoSetCompletionRoutine(irp,
>> fslxQueryDirectoryCompletionRoutine, 0, TRUE, TRUE,
>> TRUE);
>>
>> (void) IoCallDriver(DeviceObject, irp);
>>
>> KeWaitForSingleObject(&event, Executive,
>> KernelMode,
>> TRUE, 0);
>>
>> status = irp->IoStatus.Status;
>>
>> IoFreeIrp(irp);
>>
>> return status;
>> }
>>
>>
>>
>> —
>>
> === message truncated ===
>
>

3

I actually hauled the machine that this was happening
on up to the plugfest last week. Neal stayed late one
night and figured it out for us. What a guy. The
problem was only seen on win2k on some computers.
Apparently something was happening differently where
an irp got pended where it didn’t otherwise. The bug
is that the IO Manager ends up signaling the event,
when it is signaled I think that it was my completion
routine that did it, and boom.

We thought that maybe it was related to the type of
disk controller.

Neal says that the UserEvent field is owned by the IO
Manager and should never be used by filters. He said
that they ran into this internally and he will be
adding it to his “filter rules”.
— Lyndon J Clarke
wrote:

> Randy
>
> I cant find post where Neail pointed out the problem
> … I sure would like
> to understand why it is evil to put pointer to event
> in Irp->UserEvent …
>
> Thanks
> Lyndon
>
> “Randy Cook” wrote in message
> news:xxxxx@ntfsd…
> > Thanks to Neal for pointing out the problem.
> >
> > The problem is in the rolling of the irp. I was
> > passing an event to my completion routine to
> signal
> > when completion was finished. I was passing this
> by
> > putting it into Irp->UserEvent. It is plain to me
> now
> > that this is evil. The IO Manager was signaling
> the
> > event and I would mistakenly think that my
> completion
> > had done it. The solution was to pass it in the
> > context field.
> >
> > — Randy Cook wrote:
> >
> >> Below is a !analyze -v of a crash I’m only seeing
> on
> >> win2k. This happens when I roll an irp to delete
> a
> >> directory that I’ve just created.
> >>
> >> Following the output of !analyze -v is the stack
> of
> >> the thread that actually caused the crash. At
> the
> >> end
> >> is the code that rolled the irp.
> >>
> >> I looked at the device object and the file object
> >> that
> >> are handed in to the function and they appear
> valid.
> >>
> >> Any ideas? Thanks.
> >>
> >> NTFS_FILE_SYSTEM (24)
> >> If you see NtfsExceptionFilter on the stack
> then
> >> the 2nd and 3rd
> >> parameters are the exception record and
> context
> >> record. Do a .cxr
> >> on the 3rd parameter and then kb to obtain a
> >> more
> >> informative stack
> >> trace.
> >> Arguments:
> >> Arg1: 0019025e
> >> Arg2: eb43bbec
> >> Arg3: eb43b844
> >> Arg4: bff63f6d
> >>
> >> Debugging Details:
> >> ------------------
> >>
> >>
> >> EXCEPTION_RECORD: eb43bbec – (.exr
> >> ffffffffeb43bbec)
> >> ExceptionAddress: bff63f6d
> >>
> >
>
(Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x00000044)
> >> ExceptionCode: c0000005 (Access violation)
> >> ExceptionFlags: 00000000
> >> NumberParameters: 2
> >> Parameter[0]: 00000000
> >> Parameter[1]: 0000000c
> >> Attempt to read from address 0000000c
> >>
> >> CONTEXT: eb43b844 – (.cxr ffffffffeb43b844)
> >> eax=00000000 ebx=f581aa50 ecx=eb43bd30
> edx=80010031
> >> esi=e1e41868 edi=eb43bd30
> >> eip=bff63f6d esp=eb43bcb4 ebp=eb43bcf8 iopl=0
> >>
> >> nv up ei pl zr na po nc
> >> cs=0008 ss=0010 ds=0023 es=0023 fs=0030
> gs=0000
> >>
> >> efl=00210246
> >> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44:
> >> bff63f6d ff700c push dword ptr
> >> [eax+0xc]
> >> Resetting default scope
> >>
> >> DEFAULT_BUCKET_ID: DRIVER_FAULT
> >>
> >> BUGCHECK_STR: 0x24
> >>
> >> LAST_CONTROL_TRANSFER: from bff50002 to bff63f6d
> >>
> >> STACK_TEXT:
> >> eb43bcf8 bff50002 848cb5a8 e1e41868 848cb6a8
> >> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44
> >> eb43bd78 80416bfa 848cb5a8 00000000 00000000
> >> Ntfs!NtfsSpecialDispatch+0xaf
> >> eb43bda8 80454a00 848cb5a8 00000000 00000000
> >> nt!ExpWorkerThread+0xae
> >> eb43bddc 80469212 80416b4c 00000001 00000000
> >> nt!PspSystemThreadStartup+0x54
> >> 00000000 00000000 00000000 00000000 00000000
> >> nt!KiThreadStartup+0x16
> >>
> >>
> >> MODULE_NAME: Unknown_Module
> >>
> >> IMAGE_NAME: Unknown_Image
> >>
> >> DEBUG_FLR_IMAGE_TIMESTAMP: 0
> >>
> >> STACK_COMMAND: .cxr ffffffffeb43b844 ; kb
> >>
> >> BUCKET_ID: 0x24
> >> *** Followup info cannot be found !!! Please
> >> contact
> >> “Debugger Team”
> >>
> >>
> >>
> >>
> >>
> >>
> >> f541c378 8042d3c6 bff03bc0 00000000 80416aaa
> >> nt!KiUnlockDispatcherDatabase+0x73
> >> f541c384 80416aaa 804746dc 848cb6a8 bff4ff3e
> >> nt!KeInsertQueue+0x22
> >> f541c390 bff4ff3e 848cb6a8 00000001 e1e41868
> >> nt!ExQueueWorkItem+0x16
> >> f541c3ac bff003c8 827ef9a8 f581aacc bff63f29
> >> Ntfs!NtfsPostSpecial+0xd2
> >> f541c3d8 bff64065 e1e41868 00000000 c0040037
> >> Ntfs!NtfsLogEvent+0xe5
> >> f541c3f0 bff00425 827ef9a8 f581aa50 00000001
> >> Ntfs!NtfsMarkVolumeDirty+0x56
> >> f541c408 bfef8a84 827ef9a8 c0000102 00000000
> >> Ntfs!NtfsPostVcbIsCorrupt+0x17
> >> f541c424 bff1f4f8 827ef9a8 c0000102 00000000
> >> Ntfs!NtfsRaiseStatus+0x31
> >> f541c458 bff0669b 827ef9a8 c7f53430 f541c4dc
> >> Ntfs!NtfsFindInFileRecord+0x166
> >> f541c498 bff0cffb 827ef9a8 e1f02008 c7f53490
> >> Ntfs!NtfsLookupInFileRecord+0x16a
> >> f541c524 bff117dd 827ef9a8 e1f02008 f541c548
> >> Ntfs!NtfsIsFileDeleteable+0x53
> >> f541c57c bff10dc9 827ef9a8 ffa6db48 a998ae70
> >> Ntfs!NtfsSetDispositionInfo+0xf3
> >> f541c610 bff068c3 827ef9a8 a998ae70 f581a980
> >> Ntfs!NtfsCommonSetInformation+0x420
> >> f541c680 8041dded f581a980 a998ae70 000000c9
> >> Ntfs!NtfsFsdSetInformation+0xbf
> >> f541c694 80528955 f581a980 00000000 a998ae70
> >> nt!IopfCallDriver+0x35
> >> f541c6b0 f5806ef8 00000000 00100001 f541c7c8
> >> nt!IovCallDriver+0x77
> >> f541c6e0 f58163bf f581a980 ffa6db48 00000000
> >> MyDriver!MyDelete+0xbe
> >>
> >>
> >>
> >>
> >>
> >> NTSTATUS MyDelete(PDEVICE_OBJECT DeviceObject,
> >> PFILE_OBJECT FileObject, BOOLEAN deleteFlag)
> >> {
> >> NTSTATUS status;
> >> KEVENT event;
> >> PIRP irp;
> >> IO_STATUS_BLOCK IoStatusBlock;
> >> PIO_STACK_LOCATION ioStackLocation;
> >> FILE_DISPOSITION_INFORMATION fileDispositionInfo;
> >>
> >> KeInitializeEvent(&event, SynchronizationEvent,
> >> FALSE);
> >>
> >> irp = IoAllocateIrp(DeviceObject->StackSize,
> >> FALSE);
> >> if(!irp)
> >> {
> >> return ERROR_SEVERITY_ERROR;
> >> }
> >>
> >> irp->AssociatedIrp.SystemBuffer =
> >> &fileDispositionInfo;
> >> irp->UserEvent = &event;
> >> irp->Flags = IRP_BUFFERED_IO |
> IRP_SYNCHRONOUS_API;
>
=== message truncated ===

4

Randy

Gosh! Thanks for taking time with the explanation. I am right with you
regards Neal. So now starts the great Irp->UserEvent field campaign …

Cheers
Lyndoin

“Randy Cook” wrote in message news:xxxxx@ntfsd…
>I actually hauled the machine that this was happening
> on up to the plugfest last week. Neal stayed late one
> night and figured it out for us. What a guy. The
> problem was only seen on win2k on some computers.
> Apparently something was happening differently where
> an irp got pended where it didn’t otherwise. The bug
> is that the IO Manager ends up signaling the event,
> when it is signaled I think that it was my completion
> routine that did it, and boom.
>
> We thought that maybe it was related to the type of
> disk controller.
>
> Neal says that the UserEvent field is owned by the IO
> Manager and should never be used by filters. He said
> that they ran into this internally and he will be
> adding it to his “filter rules”.
> — Lyndon J Clarke
> wrote:
>
>> Randy
>>
>> I cant find post where Neail pointed out the problem
>> … I sure would like
>> to understand why it is evil to put pointer to event
>> in Irp->UserEvent …
>>
>> Thanks
>> Lyndon
>>
>> “Randy Cook” wrote in message
>> news:xxxxx@ntfsd…
>> > Thanks to Neal for pointing out the problem.
>> >
>> > The problem is in the rolling of the irp. I was
>> > passing an event to my completion routine to
>> signal
>> > when completion was finished. I was passing this
>> by
>> > putting it into Irp->UserEvent. It is plain to me
>> now
>> > that this is evil. The IO Manager was signaling
>> the
>> > event and I would mistakenly think that my
>> completion
>> > had done it. The solution was to pass it in the
>> > context field.
>> >
>> > — Randy Cook wrote:
>> >
>> >> Below is a !analyze -v of a crash I’m only seeing
>> on
>> >> win2k. This happens when I roll an irp to delete
>> a
>> >> directory that I’ve just created.
>> >>
>> >> Following the output of !analyze -v is the stack
>> of
>> >> the thread that actually caused the crash. At
>> the
>> >> end
>> >> is the code that rolled the irp.
>> >>
>> >> I looked at the device object and the file object
>> >> that
>> >> are handed in to the function and they appear
>> valid.
>> >>
>> >> Any ideas? Thanks.
>> >>
>> >> NTFS_FILE_SYSTEM (24)
>> >> If you see NtfsExceptionFilter on the stack
>> then
>> >> the 2nd and 3rd
>> >> parameters are the exception record and
>> context
>> >> record. Do a .cxr
>> >> on the 3rd parameter and then kb to obtain a
>> >> more
>> >> informative stack
>> >> trace.
>> >> Arguments:
>> >> Arg1: 0019025e
>> >> Arg2: eb43bbec
>> >> Arg3: eb43b844
>> >> Arg4: bff63f6d
>> >>
>> >> Debugging Details:
>> >> ------------------
>> >>
>> >>
>> >> EXCEPTION_RECORD: eb43bbec – (.exr
>> >> ffffffffeb43bbec)
>> >> ExceptionAddress: bff63f6d
>> >>
>> >
>>
> (Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x00000044)
>> >> ExceptionCode: c0000005 (Access violation)
>> >> ExceptionFlags: 00000000
>> >> NumberParameters: 2
>> >> Parameter[0]: 00000000
>> >> Parameter[1]: 0000000c
>> >> Attempt to read from address 0000000c
>> >>
>> >> CONTEXT: eb43b844 – (.cxr ffffffffeb43b844)
>> >> eax=00000000 ebx=f581aa50 ecx=eb43bd30
>> edx=80010031
>> >> esi=e1e41868 edi=eb43bd30
>> >> eip=bff63f6d esp=eb43bcb4 ebp=eb43bcf8 iopl=0
>> >>
>> >> nv up ei pl zr na po nc
>> >> cs=0008 ss=0010 ds=0023 es=0023 fs=0030
>> gs=0000
>> >>
>> >> efl=00210246
>> >> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44:
>> >> bff63f6d ff700c push dword ptr
>> >> [eax+0xc]
>> >> Resetting default scope
>> >>
>> >> DEFAULT_BUCKET_ID: DRIVER_FAULT
>> >>
>> >> BUGCHECK_STR: 0x24
>> >>
>> >> LAST_CONTROL_TRANSFER: from bff50002 to bff63f6d
>> >>
>> >> STACK_TEXT:
>> >> eb43bcf8 bff50002 848cb5a8 e1e41868 848cb6a8
>> >> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44
>> >> eb43bd78 80416bfa 848cb5a8 00000000 00000000
>> >> Ntfs!NtfsSpecialDispatch+0xaf
>> >> eb43bda8 80454a00 848cb5a8 00000000 00000000
>> >> nt!ExpWorkerThread+0xae
>> >> eb43bddc 80469212 80416b4c 00000001 00000000
>> >> nt!PspSystemThreadStartup+0x54
>> >> 00000000 00000000 00000000 00000000 00000000
>> >> nt!KiThreadStartup+0x16
>> >>
>> >>
>> >> MODULE_NAME: Unknown_Module
>> >>
>> >> IMAGE_NAME: Unknown_Image
>> >>
>> >> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>> >>
>> >> STACK_COMMAND: .cxr ffffffffeb43b844 ; kb
>> >>
>> >> BUCKET_ID: 0x24
>> >> *** Followup info cannot be found !!! Please
>> >> contact
>> >> “Debugger Team”
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> f541c378 8042d3c6 bff03bc0 00000000 80416aaa
>> >> nt!KiUnlockDispatcherDatabase+0x73
>> >> f541c384 80416aaa 804746dc 848cb6a8 bff4ff3e
>> >> nt!KeInsertQueue+0x22
>> >> f541c390 bff4ff3e 848cb6a8 00000001 e1e41868
>> >> nt!ExQueueWorkItem+0x16
>> >> f541c3ac bff003c8 827ef9a8 f581aacc bff63f29
>> >> Ntfs!NtfsPostSpecial+0xd2
>> >> f541c3d8 bff64065 e1e41868 00000000 c0040037
>> >> Ntfs!NtfsLogEvent+0xe5
>> >> f541c3f0 bff00425 827ef9a8 f581aa50 00000001
>> >> Ntfs!NtfsMarkVolumeDirty+0x56
>> >> f541c408 bfef8a84 827ef9a8 c0000102 00000000
>> >> Ntfs!NtfsPostVcbIsCorrupt+0x17
>> >> f541c424 bff1f4f8 827ef9a8 c0000102 00000000
>> >> Ntfs!NtfsRaiseStatus+0x31
>> >> f541c458 bff0669b 827ef9a8 c7f53430 f541c4dc
>> >> Ntfs!NtfsFindInFileRecord+0x166
>> >> f541c498 bff0cffb 827ef9a8 e1f02008 c7f53490
>> >> Ntfs!NtfsLookupInFileRecord+0x16a
>> >> f541c524 bff117dd 827ef9a8 e1f02008 f541c548
>> >> Ntfs!NtfsIsFileDeleteable+0x53
>> >> f541c57c bff10dc9 827ef9a8 ffa6db48 a998ae70
>> >> Ntfs!NtfsSetDispositionInfo+0xf3
>> >> f541c610 bff068c3 827ef9a8 a998ae70 f581a980
>> >> Ntfs!NtfsCommonSetInformation+0x420
>> >> f541c680 8041dded f581a980 a998ae70 000000c9
>> >> Ntfs!NtfsFsdSetInformation+0xbf
>> >> f541c694 80528955 f581a980 00000000 a998ae70
>> >> nt!IopfCallDriver+0x35
>> >> f541c6b0 f5806ef8 00000000 00100001 f541c7c8
>> >> nt!IovCallDriver+0x77
>> >> f541c6e0 f58163bf f581a980 ffa6db48 00000000
>> >> MyDriver!MyDelete+0xbe
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> NTSTATUS MyDelete(PDEVICE_OBJECT DeviceObject,
>> >> PFILE_OBJECT FileObject, BOOLEAN deleteFlag)
>> >> {
>> >> NTSTATUS status;
>> >> KEVENT event;
>> >> PIRP irp;
>> >> IO_STATUS_BLOCK IoStatusBlock;
>> >> PIO_STACK_LOCATION ioStackLocation;
>> >> FILE_DISPOSITION_INFORMATION fileDispositionInfo;
>> >>
>> >> KeInitializeEvent(&event, SynchronizationEvent,
>> >> FALSE);
>> >>
>> >> irp = IoAllocateIrp(DeviceObject->StackSize,
>> >> FALSE);
>> >> if(!irp)
>> >> {
>> >> return ERROR_SEVERITY_ERROR;
>> >> }
>> >>
>> >> irp->AssociatedIrp.SystemBuffer =
>> >> &fileDispositionInfo;
>> >> irp->UserEvent = &event;
>> >> irp->Flags = IRP_BUFFERED_IO |
>> IRP_SYNCHRONOUS_API;
>>
> === message truncated ===
>
>

5

Does this apply to cases where a filter builds its own IRP?

Kem

-----Original Message-----
From: Lyndon J Clarke [mailto:xxxxx@neverfailgroup.com]
Sent: Saturday, May 07, 2005 2:12 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Re:win2k crash deleting directory – resolved!

Randy

Gosh! Thanks for taking time with the explanation. I am right with you
regards Neal. So now starts the great Irp->UserEvent field campaign …

Cheers
Lyndoin

“Randy Cook” wrote in message news:xxxxx@ntfsd…
>I actually hauled the machine that this was happening
> on up to the plugfest last week. Neal stayed late one
> night and figured it out for us. What a guy. The
> problem was only seen on win2k on some computers.
> Apparently something was happening differently where
> an irp got pended where it didn’t otherwise. The bug
> is that the IO Manager ends up signaling the event,
> when it is signaled I think that it was my completion
> routine that did it, and boom.
>
> We thought that maybe it was related to the type of
> disk controller.
>
> Neal says that the UserEvent field is owned by the IO
> Manager and should never be used by filters. He said
> that they ran into this internally and he will be
> adding it to his “filter rules”.
> — Lyndon J Clarke
> wrote:
>
>> Randy
>>
>> I cant find post where Neail pointed out the problem
>> … I sure would like
>> to understand why it is evil to put pointer to event
>> in Irp->UserEvent …
>>
>> Thanks
>> Lyndon
>>
>> “Randy Cook” wrote in message
>> news:xxxxx@ntfsd…
>> > Thanks to Neal for pointing out the problem.
>> >
>> > The problem is in the rolling of the irp. I was
>> > passing an event to my completion routine to
>> signal
>> > when completion was finished. I was passing this
>> by
>> > putting it into Irp->UserEvent. It is plain to me
>> now
>> > that this is evil. The IO Manager was signaling
>> the
>> > event and I would mistakenly think that my
>> completion
>> > had done it. The solution was to pass it in the
>> > context field.
>> >
>> > — Randy Cook wrote:
>> >
>> >> Below is a !analyze -v of a crash I’m only seeing
>> on
>> >> win2k. This happens when I roll an irp to delete
>> a
>> >> directory that I’ve just created.
>> >>
>> >> Following the output of !analyze -v is the stack
>> of
>> >> the thread that actually caused the crash. At
>> the
>> >> end
>> >> is the code that rolled the irp.
>> >>
>> >> I looked at the device object and the file object
>> >> that
>> >> are handed in to the function and they appear
>> valid.
>> >>
>> >> Any ideas? Thanks.
>> >>
>> >> NTFS_FILE_SYSTEM (24)
>> >> If you see NtfsExceptionFilter on the stack
>> then
>> >> the 2nd and 3rd
>> >> parameters are the exception record and
>> context
>> >> record. Do a .cxr
>> >> on the 3rd parameter and then kb to obtain a
>> >> more
>> >> informative stack
>> >> trace.
>> >> Arguments:
>> >> Arg1: 0019025e
>> >> Arg2: eb43bbec
>> >> Arg3: eb43b844
>> >> Arg4: bff63f6d
>> >>
>> >> Debugging Details:
>> >> ------------------
>> >>
>> >>
>> >> EXCEPTION_RECORD: eb43bbec – (.exr
>> >> ffffffffeb43bbec)
>> >> ExceptionAddress: bff63f6d
>> >>
>> >
>>
> (Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x00000044)
>> >> ExceptionCode: c0000005 (Access violation)
>> >> ExceptionFlags: 00000000
>> >> NumberParameters: 2
>> >> Parameter[0]: 00000000
>> >> Parameter[1]: 0000000c
>> >> Attempt to read from address 0000000c
>> >>
>> >> CONTEXT: eb43b844 – (.cxr ffffffffeb43b844)
>> >> eax=00000000 ebx=f581aa50 ecx=eb43bd30
>> edx=80010031
>> >> esi=e1e41868 edi=eb43bd30
>> >> eip=bff63f6d esp=eb43bcb4 ebp=eb43bcf8 iopl=0
>> >>
>> >> nv up ei pl zr na po nc
>> >> cs=0008 ss=0010 ds=0023 es=0023 fs=0030
>> gs=0000
>> >>
>> >> efl=00210246
>> >> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44:
>> >> bff63f6d ff700c push dword ptr
>> >> [eax+0xc]
>> >> Resetting default scope
>> >>
>> >> DEFAULT_BUCKET_ID: DRIVER_FAULT
>> >>
>> >> BUGCHECK_STR: 0x24
>> >>
>> >> LAST_CONTROL_TRANSFER: from bff50002 to bff63f6d
>> >>
>> >> STACK_TEXT:
>> >> eb43bcf8 bff50002 848cb5a8 e1e41868 848cb6a8
>> >> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44
>> >> eb43bd78 80416bfa 848cb5a8 00000000 00000000
>> >> Ntfs!NtfsSpecialDispatch+0xaf
>> >> eb43bda8 80454a00 848cb5a8 00000000 00000000
>> >> nt!ExpWorkerThread+0xae
>> >> eb43bddc 80469212 80416b4c 00000001 00000000
>> >> nt!PspSystemThreadStartup+0x54
>> >> 00000000 00000000 00000000 00000000 00000000
>> >> nt!KiThreadStartup+0x16
>> >>
>> >>
>> >> MODULE_NAME: Unknown_Module
>> >>
>> >> IMAGE_NAME: Unknown_Image
>> >>
>> >> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>> >>
>> >> STACK_COMMAND: .cxr ffffffffeb43b844 ; kb
>> >>
>> >> BUCKET_ID: 0x24
>> >> *** Followup info cannot be found !!! Please
>> >> contact
>> >> “Debugger Team”
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> f541c378 8042d3c6 bff03bc0 00000000 80416aaa
>> >> nt!KiUnlockDispatcherDatabase+0x73
>> >> f541c384 80416aaa 804746dc 848cb6a8 bff4ff3e
>> >> nt!KeInsertQueue+0x22
>> >> f541c390 bff4ff3e 848cb6a8 00000001 e1e41868
>> >> nt!ExQueueWorkItem+0x16
>> >> f541c3ac bff003c8 827ef9a8 f581aacc bff63f29
>> >> Ntfs!NtfsPostSpecial+0xd2
>> >> f541c3d8 bff64065 e1e41868 00000000 c0040037
>> >> Ntfs!NtfsLogEvent+0xe5
>> >> f541c3f0 bff00425 827ef9a8 f581aa50 00000001
>> >> Ntfs!NtfsMarkVolumeDirty+0x56
>> >> f541c408 bfef8a84 827ef9a8 c0000102 00000000
>> >> Ntfs!NtfsPostVcbIsCorrupt+0x17
>> >> f541c424 bff1f4f8 827ef9a8 c0000102 00000000
>> >> Ntfs!NtfsRaiseStatus+0x31
>> >> f541c458 bff0669b 827ef9a8 c7f53430 f541c4dc
>> >> Ntfs!NtfsFindInFileRecord+0x166
>> >> f541c498 bff0cffb 827ef9a8 e1f02008 c7f53490
>> >> Ntfs!NtfsLookupInFileRecord+0x16a
>> >> f541c524 bff117dd 827ef9a8 e1f02008 f541c548
>> >> Ntfs!NtfsIsFileDeleteable+0x53
>> >> f541c57c bff10dc9 827ef9a8 ffa6db48 a998ae70
>> >> Ntfs!NtfsSetDispositionInfo+0xf3
>> >> f541c610 bff068c3 827ef9a8 a998ae70 f581a980
>> >> Ntfs!NtfsCommonSetInformation+0x420
>> >> f541c680 8041dded f581a980 a998ae70 000000c9
>> >> Ntfs!NtfsFsdSetInformation+0xbf
>> >> f541c694 80528955 f581a980 00000000 a998ae70
>> >> nt!IopfCallDriver+0x35
>> >> f541c6b0 f5806ef8 00000000 00100001 f541c7c8
>> >> nt!IovCallDriver+0x77
>> >> f541c6e0 f58163bf f581a980 ffa6db48 00000000
>> >> MyDriver!MyDelete+0xbe
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> NTSTATUS MyDelete(PDEVICE_OBJECT DeviceObject,
>> >> PFILE_OBJECT FileObject, BOOLEAN deleteFlag)
>> >> {
>> >> NTSTATUS status;
>> >> KEVENT event;
>> >> PIRP irp;
>> >> IO_STATUS_BLOCK IoStatusBlock;
>> >> PIO_STACK_LOCATION ioStackLocation;
>> >> FILE_DISPOSITION_INFORMATION fileDispositionInfo;
>> >>
>> >> KeInitializeEvent(&event, SynchronizationEvent,
>> >> FALSE);
>> >>
>> >> irp = IoAllocateIrp(DeviceObject->StackSize,
>> >> FALSE);
>> >> if(!irp)
>> >> {
>> >> return ERROR_SEVERITY_ERROR;
>> >> }
>> >>
>> >> irp->AssociatedIrp.SystemBuffer =
>> >> &fileDispositionInfo;
>> >> irp->UserEvent = &event;
>> >> irp->Flags = IRP_BUFFERED_IO |
>> IRP_SYNCHRONOUS_API;
>>
> === message truncated ===
>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

6

Yes sir. That is exactly what my filter was
doing…rolling its own irp.

— Ken Galipeau wrote:

> Does this apply to cases where a filter builds its
> own IRP?
>
> Kem
>
> -----Original Message-----
> From: Lyndon J Clarke
> [mailto:xxxxx@neverfailgroup.com]
> Sent: Saturday, May 07, 2005 2:12 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Re:win2k crash deleting
> directory – resolved!
>
> Randy
>
> Gosh! Thanks for taking time with the explanation. I
> am right with you
> regards Neal. So now starts the great Irp->UserEvent
> field campaign …
>
> Cheers
> Lyndoin
>
> “Randy Cook” wrote in message
> news:xxxxx@ntfsd…
> >I actually hauled the machine that this was
> happening
> > on up to the plugfest last week. Neal stayed late
> one
> > night and figured it out for us. What a guy. The
> > problem was only seen on win2k on some computers.
> > Apparently something was happening differently
> where
> > an irp got pended where it didn’t otherwise. The
> bug
> > is that the IO Manager ends up signaling the
> event,
> > when it is signaled I think that it was my
> completion
> > routine that did it, and boom.
> >
> > We thought that maybe it was related to the type
> of
> > disk controller.
> >
> > Neal says that the UserEvent field is owned by the
> IO
> > Manager and should never be used by filters. He
> said
> > that they ran into this internally and he will be
> > adding it to his “filter rules”.
> > — Lyndon J Clarke
> > wrote:
> >
> >> Randy
> >>
> >> I cant find post where Neail pointed out the
> problem
> >> … I sure would like
> >> to understand why it is evil to put pointer to
> event
> >> in Irp->UserEvent …
> >>
> >> Thanks
> >> Lyndon
> >>
> >> “Randy Cook” wrote in
> message
> >> news:xxxxx@ntfsd…
> >> > Thanks to Neal for pointing out the problem.
> >> >
> >> > The problem is in the rolling of the irp. I
> was
> >> > passing an event to my completion routine to
> >> signal
> >> > when completion was finished. I was passing
> this
> >> by
> >> > putting it into Irp->UserEvent. It is plain to
> me
> >> now
> >> > that this is evil. The IO Manager was
> signaling
> >> the
> >> > event and I would mistakenly think that my
> >> completion
> >> > had done it. The solution was to pass it in
> the
> >> > context field.
> >> >
> >> > — Randy Cook wrote:
> >> >
> >> >> Below is a !analyze -v of a crash I’m only
> seeing
> >> on
> >> >> win2k. This happens when I roll an irp to
> delete
> >> a
> >> >> directory that I’ve just created.
> >> >>
> >> >> Following the output of !analyze -v is the
> stack
> >> of
> >> >> the thread that actually caused the crash. At
> >> the
> >> >> end
> >> >> is the code that rolled the irp.
> >> >>
> >> >> I looked at the device object and the file
> object
> >> >> that
> >> >> are handed in to the function and they appear
> >> valid.
> >> >>
> >> >> Any ideas? Thanks.
> >> >>
> >> >> NTFS_FILE_SYSTEM (24)
> >> >> If you see NtfsExceptionFilter on the
> stack
> >> then
> >> >> the 2nd and 3rd
> >> >> parameters are the exception record and
> >> context
> >> >> record. Do a .cxr
> >> >> on the 3rd parameter and then kb to obtain
> a
> >> >> more
> >> >> informative stack
> >> >> trace.
> >> >> Arguments:
> >> >> Arg1: 0019025e
> >> >> Arg2: eb43bbec
> >> >> Arg3: eb43b844
> >> >> Arg4: bff63f6d
> >> >>
> >> >> Debugging Details:
> >> >> ------------------
> >> >>
> >> >>
> >> >> EXCEPTION_RECORD: eb43bbec – (.exr
> >> >> ffffffffeb43bbec)
> >> >> ExceptionAddress: bff63f6d
> >> >>
> >> >
> >>
> >
>
(Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x00000044)
> >> >> ExceptionCode: c0000005 (Access violation)
> >> >> ExceptionFlags: 00000000
> >> >> NumberParameters: 2
> >> >> Parameter[0]: 00000000
> >> >> Parameter[1]: 0000000c
> >> >> Attempt to read from address 0000000c
> >> >>
> >> >> CONTEXT: eb43b844 – (.cxr ffffffffeb43b844)
> >> >> eax=00000000 ebx=f581aa50 ecx=eb43bd30
> >> edx=80010031
> >> >> esi=e1e41868 edi=eb43bd30
> >> >> eip=bff63f6d esp=eb43bcb4 ebp=eb43bcf8 iopl=0
> >> >>
> >> >> nv up ei pl zr na po nc
> >> >> cs=0008 ss=0010 ds=0023 es=0023 fs=0030
> >> gs=0000
> >> >>
> >> >> efl=00210246
> >> >> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44:
> >> >> bff63f6d ff700c push dword ptr
> >> >> [eax+0xc]
> >> >> Resetting default scope
> >> >>
> >> >> DEFAULT_BUCKET_ID: DRIVER_FAULT
> >> >>
> >> >> BUGCHECK_STR: 0x24
> >> >>
> >> >> LAST_CONTROL_TRANSFER: from bff50002 to
> bff63f6d
> >> >>
> >> >> STACK_TEXT:
> >> >> eb43bcf8 bff50002 848cb5a8 e1e41868 848cb6a8
> >> >> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44
> >> >> eb43bd78 80416bfa 848cb5a8 00000000 00000000
> >> >> Ntfs!NtfsSpecialDispatch+0xaf
> >> >> eb43bda8 80454a00 848cb5a8 00000000 00000000
> >> >> nt!ExpWorkerThread+0xae
> >> >> eb43bddc 80469212 80416b4c 00000001 00000000
> >> >> nt!PspSystemThreadStartup+0x54
> >> >> 00000000 00000000 00000000 00000000 00000000
> >> >> nt!KiThreadStartup+0x16
> >> >>
> >> >>
> >> >> MODULE_NAME: Unknown_Module
> >> >>
> >> >> IMAGE_NAME: Unknown_Image
> >> >>
> >> >> DEBUG_FLR_IMAGE_TIMESTAMP: 0
> >> >>
> >> >> STACK_COMMAND: .cxr ffffffffeb43b844 ; kb
> >> >>
> >> >> BUCKET_ID: 0x24
> >> >> *** Followup info cannot be found !!! Please
> >> >> contact
>
=== message truncated ===

7

Yikes! So what are the symptoms of doing this? i.e. How might the system
crash?

Ken

-----Original Message-----
From: Randy Cook [mailto:xxxxx@yahoo.com]
Sent: Thursday, May 19, 2005 1:33 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Re:win2k crash deleting directory – resolved!

Yes sir. That is exactly what my filter was
doing…rolling its own irp.

— Ken Galipeau wrote:

> Does this apply to cases where a filter builds its
> own IRP?
>
> Kem
>
> -----Original Message-----
> From: Lyndon J Clarke
> [mailto:xxxxx@neverfailgroup.com]
> Sent: Saturday, May 07, 2005 2:12 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Re:win2k crash deleting
> directory – resolved!
>
> Randy
>
> Gosh! Thanks for taking time with the explanation. I
> am right with you
> regards Neal. So now starts the great Irp->UserEvent
> field campaign …
>
> Cheers
> Lyndoin
>
> “Randy Cook” wrote in message
> news:xxxxx@ntfsd…
> >I actually hauled the machine that this was
> happening
> > on up to the plugfest last week. Neal stayed late
> one
> > night and figured it out for us. What a guy. The
> > problem was only seen on win2k on some computers.
> > Apparently something was happening differently
> where
> > an irp got pended where it didn’t otherwise. The
> bug
> > is that the IO Manager ends up signaling the
> event,
> > when it is signaled I think that it was my
> completion
> > routine that did it, and boom.
> >
> > We thought that maybe it was related to the type
> of
> > disk controller.
> >
> > Neal says that the UserEvent field is owned by the
> IO
> > Manager and should never be used by filters. He
> said
> > that they ran into this internally and he will be
> > adding it to his “filter rules”.
> > — Lyndon J Clarke
> > wrote:
> >
> >> Randy
> >>
> >> I cant find post where Neail pointed out the
> problem
> >> … I sure would like
> >> to understand why it is evil to put pointer to
> event
> >> in Irp->UserEvent …
> >>
> >> Thanks
> >> Lyndon
> >>
> >> “Randy Cook” wrote in
> message
> >> news:xxxxx@ntfsd…
> >> > Thanks to Neal for pointing out the problem.
> >> >
> >> > The problem is in the rolling of the irp. I
> was
> >> > passing an event to my completion routine to
> >> signal
> >> > when completion was finished. I was passing
> this
> >> by
> >> > putting it into Irp->UserEvent. It is plain to
> me
> >> now
> >> > that this is evil. The IO Manager was
> signaling
> >> the
> >> > event and I would mistakenly think that my
> >> completion
> >> > had done it. The solution was to pass it in
> the
> >> > context field.
> >> >
> >> > — Randy Cook wrote:
> >> >
> >> >> Below is a !analyze -v of a crash I’m only
> seeing
> >> on
> >> >> win2k. This happens when I roll an irp to
> delete
> >> a
> >> >> directory that I’ve just created.
> >> >>
> >> >> Following the output of !analyze -v is the
> stack
> >> of
> >> >> the thread that actually caused the crash. At
> >> the
> >> >> end
> >> >> is the code that rolled the irp.
> >> >>
> >> >> I looked at the device object and the file
> object
> >> >> that
> >> >> are handed in to the function and they appear
> >> valid.
> >> >>
> >> >> Any ideas? Thanks.
> >> >>
> >> >> NTFS_FILE_SYSTEM (24)
> >> >> If you see NtfsExceptionFilter on the
> stack
> >> then
> >> >> the 2nd and 3rd
> >> >> parameters are the exception record and
> >> context
> >> >> record. Do a .cxr
> >> >> on the 3rd parameter and then kb to obtain
> a
> >> >> more
> >> >> informative stack
> >> >> trace.
> >> >> Arguments:
> >> >> Arg1: 0019025e
> >> >> Arg2: eb43bbec
> >> >> Arg3: eb43b844
> >> >> Arg4: bff63f6d
> >> >>
> >> >> Debugging Details:
> >> >> ------------------
> >> >>
> >> >>
> >> >> EXCEPTION_RECORD: eb43bbec – (.exr
> >> >> ffffffffeb43bbec)
> >> >> ExceptionAddress: bff63f6d
> >> >>
> >> >
> >>
> >
>
(Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x00000044)
> >> >> ExceptionCode: c0000005 (Access violation)
> >> >> ExceptionFlags: 00000000
> >> >> NumberParameters: 2
> >> >> Parameter[0]: 00000000
> >> >> Parameter[1]: 0000000c
> >> >> Attempt to read from address 0000000c
> >> >>
> >> >> CONTEXT: eb43b844 – (.cxr ffffffffeb43b844)
> >> >> eax=00000000 ebx=f581aa50 ecx=eb43bd30
> >> edx=80010031
> >> >> esi=e1e41868 edi=eb43bd30
> >> >> eip=bff63f6d esp=eb43bcb4 ebp=eb43bcf8 iopl=0
> >> >>
> >> >> nv up ei pl zr na po nc
> >> >> cs=0008 ss=0010 ds=0023 es=0023 fs=0030
> >> gs=0000
> >> >>
> >> >> efl=00210246
> >> >> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44:
> >> >> bff63f6d ff700c push dword ptr
> >> >> [eax+0xc]
> >> >> Resetting default scope
> >> >>
> >> >> DEFAULT_BUCKET_ID: DRIVER_FAULT
> >> >>
> >> >> BUGCHECK_STR: 0x24
> >> >>
> >> >> LAST_CONTROL_TRANSFER: from bff50002 to
> bff63f6d
> >> >>
> >> >> STACK_TEXT:
> >> >> eb43bcf8 bff50002 848cb5a8 e1e41868 848cb6a8
> >> >> Ntfs!NtfsResolveVolumeAndLogEventSpecial+0x44
> >> >> eb43bd78 80416bfa 848cb5a8 00000000 00000000
> >> >> Ntfs!NtfsSpecialDispatch+0xaf
> >> >> eb43bda8 80454a00 848cb5a8 00000000 00000000
> >> >> nt!ExpWorkerThread+0xae
> >> >> eb43bddc 80469212 80416b4c 00000001 00000000
> >> >> nt!PspSystemThreadStartup+0x54
> >> >> 00000000 00000000 00000000 00000000 00000000
> >> >> nt!KiThreadStartup+0x16
> >> >>
> >> >>
> >> >> MODULE_NAME: Unknown_Module
> >> >>
> >> >> IMAGE_NAME: Unknown_Image
> >> >>
> >> >> DEBUG_FLR_IMAGE_TIMESTAMP: 0
> >> >>
> >> >> STACK_COMMAND: .cxr ffffffffeb43b844 ; kb
> >> >>
> >> >> BUCKET_ID: 0x24
> >> >> *** Followup info cannot be found !!! Please
> >> >> contact
>
=== message truncated ===

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

8

> Yikes! So what are the symptoms of doing this? i.e.

How might the system
crash?

Blue screen with lots of funny numbers :slight_smile:

See the original post for the !analyze -v output.

I only saw this on a small subset of W2K machines.
Neal theorized that it was a particular disk driver
that was triggering the crash. Whatever it was, the
result was that the IRP got pended, IOManager signaled
the event, I assumed that the irp had completed, and
boom.

Fortunately, not a difficult or risky fix.