win2k crash deleting directory

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;
}

Maybe this is at least worth check:

what is the value of your “deleteFlag” parameter ?
If it is TRUE, the original NtSetInformationFile
sets the ioStackLocation->Parameters.SetFile.DeleteHandle.

irp->Flags = IRP_BUFFERED_IO | IRP_SYNCHRONOUS_API;

IRP_SYNCHRONOUS_API is set only if the FO_SYNCHRONOUS_IO
is set in the file object (but again, I cannot say that this is the problem)

It is also worth test to compare your built IRP with
the one that is created by NtSetInformationFile.
Try to call this function and compare your IRP
with the IRP created by the function. Maybe you
find some difference that will change it.

L.

----- Original Message -----
From: “Randy Cook”
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, April 26, 2005 12:56 AM
Subject: [ntfsd] win2k crash deleting directory

> 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;
> }
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@volny.cz
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>