Bugcheck NTFS_FILE_SYSTEM (24)

OSR_Community_User · February 3, 2004, 4:57am

Hi all,

I’ve got a very strange BSOD one a machine our filter driver is running on.
I’ve just started supporting kernel mode software, so please don’t pick on
me in case the following assumptions arr wrong…

This is what (I think) I found out:

Our filter driver provides HSM functinality. The IvdFioQueryStandardInfo
function first calls the lower level fastio routine and then checks the
attributes of the file in question. This is done by creating an IRP
(IRP_MJ_QUERY_INFORMATION, BasicInfo) and sending it down to NTFS. Usually
this code works, but under certain circumstances (when called by
StorageArchive.exe) sometimes this BSOD occurs. I’ve checked the code that
creates the IRP serveral times against the samples in this list, but I
couldn’t find what’s wrong.

What seems strange:

The return adress of 8041db79 on the stack for
Ntfs!NtfsFsdQueryInformation
be3f1990 8041db79 81c03760 8135e948 be3f1a74
Ntfs!NtfsFsdQueryInformation+0xd7
Strange parameters in on the stack for nt!IopfCallDriver
be3f19a4 be12f25c 815daf00 8135eab4 00000000 nt!IopfCallDriver+0x35

1st parameter should be the device object which seems to be fine:

1: kd> !object 815daf00
Object: 815daf00 Type: (820807a0) Device
ObjectHeader: 815daee8
HandleCount: 0 PointerCount: 1

2nd parameter is supposed to be the irp. (which seems to be wrong)
1: kd> !irp 8135eab4
IRP signature does not match, probably not an IRP

When I check the irp in my local parameters it has a differnt adress and can
be displayed:
1: kd> !irp 8135e948
Irp is active with 8 stacks 8 is current (= 0x8135eab4)
No Mdl Irp count = be3f1a4c Thread 8168caa0: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[5, 0] 0 e0 81c03760 81237978 be12f020-00000000 Success Error Cancel
\FileSystem\Ntfs IvdIFS_G!IvdIrpGetInfoCompl
Args: 00000028 00000004 00000000 00000000

Does anybody have an idea what’s wrong on this system ?

Thanks for any help in advance,

Lars

Debugger output:

Symbol search path is:
srv*D:\Debug\DbgSymbols*http://msdl.microsoft.com/download/symbols;D:\Debug\
dumps\grau-test20-040127\sym

Loading Dump File [D:\Debug\dumps\grau-test20-040127\MEMORY.DMP]
Kernel Dump File: Full address space is available

Symbol search path is:
srv*D:\Debug\DbgSymbols*http://msdl.microsoft.com/download/symbols;D:\Debug\
dumps\grau-test20-040127\sym
Executable search path is:
Windows 2000 Kernel Version 2195 (Service Pack 3) MP (2 procs) Free x86
compatible
Product: Server
Kernel base = 0x80400000 PsLoadedModuleList = 0x80483fa0
Debug session time: Tue Jan 27 18:32:06 2004
System Uptime: 0 days 2:46:59.484
Loading Kernel Symbols
…
…
Loading unloaded module list
…
Loading User Symbols
…
…
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

Use !analyze -v to get detailed debugging information.

BugCheck 24, {19025e, be3f16ac, be3f1304, bfef1501}

*** ERROR: Symbol file could not be found. Defaulted to export symbols for
SYMEVENT.SYS -
*** WARNING: Unable to verify checksum for StorageCommon.DLL
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
StorageCommon.DLL -
*** WARNING: Unable to verify checksum for StorageArchive.exe
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
StorageArchive.exe -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
MSVCRT.dll -
Probably caused by : IvdIFS_G.sys ( IvdIFS_G!IvdIrpGetBasicInfoBase+1ac )

Followup: MachineOwner

1: kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

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: be3f16ac
Arg3: be3f1304
Arg4: bfef1501

Debugging Details:

EXCEPTION_RECORD: be3f16ac – (.exr ffffffffbe3f16ac)
ExceptionAddress: bfef1501 (Ntfs!NtfsQueryBasicInfo+0x00000085)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000004
Attempt to read from address 00000004

CONTEXT: be3f1304 – (.cxr ffffffffbe3f1304)
eax=00000000 ebx=e3d490d8 ecx=00000000 edx=be3f1a4c esi=e3d49008
edi=be3f1a74
eip=bfef1501 esp=be3f1774 ebp=be3f181c iopl=0 nv up ei pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
Ntfs!NtfsQueryBasicInfo+85:
bfef1501 f6400402 test byte ptr [eax+0x4],0x2
ds:0023:00000004=??
Resetting default context

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from bfef0902 to bfef1501

STACK_TEXT:
be3f177c bfef0902 be3f1864 81237978 e3d490d8 Ntfs!NtfsQueryBasicInfo+0x85
be3f181c bfef1245 be3f1864 8135e948 81c03760
Ntfs!NtfsCommonQueryInformation+0x1fe
be3f1990 8041db79 81c03760 8135e948 be3f1a74
Ntfs!NtfsFsdQueryInformation+0xd7
be3f19a4 be12f25c 815daf00 8135eab4 00000000 nt!IopfCallDriver+0x35
be3f19dc be12f2de 81c03760 81237978 be3f1a4c
IvdIFS_G!IvdIrpGetBasicInfoBase+0x1ac [ivdifs_myirp.c @ 212]
be3f19f4 be12551e 81237978 81c03760 be3f1a4c
IvdIFS_G!IvdIrpGetBasicInfo+0x2e [ivdifs_myirp.c @ 241]
be3f1a80 be2d43c8 81237978 00000001 be3f1acc
IvdIFS_G!IvdFioQueryStandardInfo+0x1be [ivdifs_fastio.c @ 274]
WARNING: Stack unwind information not available. Following frames may be
wrong.
be3f1aa4 8049bee9 81237978 00000001 be3f1acc SYMEVENT+0x23c8
be3f1afc 804d34b0 81237978 be3f1b9c 00000000 nt!FsRtlGetFileSize+0x35
be3f1ba4 8043badc e37eb3d0 be3f1c98 00000000 nt!MmExtendSection+0xf6
be3f1cc8 804cb231 be3f1d1c 000f0007 00000000 nt!MmCreateSection+0xa16
be3f1d40 80465ee9 0102d25c 000f0007 00000000 nt!NtCreateSection+0x129
be3f1d40 77f88293 0102d25c 000f0007 00000000 nt!KiSystemService+0xc9
0102d200 7c586f1e 0102d25c 000f0007 00000000 ntdll!NtCreateSection+0xb
0102d260 1003792b 000000a8 00000000 00000004
KERNEL32!CreateFileMappingW+0xd7
0102d4a8 004079e9 0052c6d0 01a16560 00000000
StorageCommon!CVaultParameters::GetVaultType+0x326e
0102ff40 00408b72 01cff78c 00000000 00528870
StorageArchive!CParametersMessage::operator=+0x3508
0102ff80 780060ce 00cff78c 00000000 00000000
StorageArchive!CParametersMessage::operator=+0x4691
0102ffb4 7c57b382 00528870 00000000 00000000 MSVCRT!beginthreadex+0xb2
0102ffec 00000000 78006073 00528870 00000000 KERNEL32!BaseThreadStart+0x52

FOLLOWUP_IP:
IvdIFS_G!IvdIrpGetBasicInfoBase+1ac
be12f25c 8945dc mov [ebp-0x24],eax

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: IvdIFS_G!IvdIrpGetBasicInfoBase+1ac

MODULE_NAME: IvdIFS_G

IMAGE_NAME: IvdIFS_G.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3fd474c2

STACK_COMMAND: .cxr ffffffffbe3f1304 ; kb

BUCKET_ID: 0x24_IvdIFS_G!IvdIrpGetBasicInfoBase+1ac

Followup: MachineOwner

Code for rolling the IRP:

memset(pFileBasicInfo, 0, sizeof(FILE_BASIC_INFORMATION));

// Initialize the event
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

// Allocate an irp for this request. \todo This could also come from a
// private pool, for instance.
irp = IoAllocateIrp(DeviceObject->StackSize, FALSE);

if (!irp) {
// Failure!
return STATUS_NO_MEMORY;
};

// Build the IRP’s main body
irp->AssociatedIrp.SystemBuffer = pFileBasicInfo;
irp->UserEvent = &event;
irp->UserIosb = &IoStatusBlock;
irp->Tail.Overlay.Thread = PsGetCurrentThread();
irp->Tail.Overlay.OriginalFileObject = FileObject;
irp->RequestorMode = KernelMode;
irp->Flags = (IRP_SYNCHRONOUS_API|IRP_BUFFERED_IO);

// Set up the I/O stack location.
ioStackLocation = IoGetNextIrpStackLocation(irp);
ioStackLocation->MajorFunction = IRP_MJ_QUERY_INFORMATION;
ioStackLocation->DeviceObject = DeviceObject;
ioStackLocation->FileObject = FileObject;
ioStackLocation->Parameters.QueryFile.Length =
sizeof(FILE_BASIC_INFORMATION);
ioStackLocation->Parameters.QueryFile.FileInformationClass =
FileBasicInformation;

// Set the completion routine.
IoSetCompletionRoutine(irp, IvdIrpGetInfoCompl, 0, TRUE, TRUE, TRUE);

ntStatus = IoCallDriver(DeviceObject, irp);
if (ntStatus==STATUS_PENDING) {
KeWaitForSingleObject(&event, Executive, KernelMode, FALSE, NULL);
ntStatus = IoStatusBlock.Status;
};

Nick_Ryan · February 4, 2004, 12:25am

From the looks of the stack, you’re querying for basic info while
processing a get file size request with the IRP_PAGING_IO flag set (Mm
pre-acquires filesystem locks prior to extending a section). You’re very
restricted in the type of requests you can fire off to the underlying
filesystem while blocking a paging I/O request, due to locking issues.
It may be safe to query for basic info, but as a rule of thumb I would
not do this.

Having said that, your immediate issue may be different, since the
situation I just described would most likely result in a deadlock, not a
crash.

Lars Diehl wrote:

Hi all,

I’ve got a very strange BSOD one a machine our filter driver is running on.
I’ve just started supporting kernel mode software, so please don’t pick on
me in case the following assumptions arr wrong…

This is what (I think) I found out:

Our filter driver provides HSM functinality. The IvdFioQueryStandardInfo
function first calls the lower level fastio routine and then checks the
attributes of the file in question. This is done by creating an IRP
(IRP_MJ_QUERY_INFORMATION, BasicInfo) and sending it down to NTFS. Usually
this code works, but under certain circumstances (when called by
StorageArchive.exe) sometimes this BSOD occurs. I’ve checked the code that
creates the IRP serveral times against the samples in this list, but I
couldn’t find what’s wrong.

What seems strange:

The return adress of 8041db79 on the stack for
Ntfs!NtfsFsdQueryInformation
be3f1990 8041db79 81c03760 8135e948 be3f1a74
Ntfs!NtfsFsdQueryInformation+0xd7

Strange parameters in on the stack for nt!IopfCallDriver
be3f19a4 be12f25c 815daf00 8135eab4 00000000 nt!IopfCallDriver+0x35

1st parameter should be the device object which seems to be fine:

1: kd> !object 815daf00
Object: 815daf00 Type: (820807a0) Device
ObjectHeader: 815daee8
HandleCount: 0 PointerCount: 1

2nd parameter is supposed to be the irp. (which seems to be wrong)
1: kd> !irp 8135eab4
IRP signature does not match, probably not an IRP

When I check the irp in my local parameters it has a differnt adress and can
be displayed:
1: kd> !irp 8135e948
Irp is active with 8 stacks 8 is current (= 0x8135eab4)
No Mdl Irp count = be3f1a4c Thread 8168caa0: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

>[5, 0] 0 e0 81c03760 81237978 be12f020-00000000 Success Error Cancel

\FileSystem\Ntfs IvdIFS_G!IvdIrpGetInfoCompl
Args: 00000028 00000004 00000000 00000000

Does anybody have an idea what’s wrong on this system ?

Thanks for any help in advance,

Lars

Debugger output:

Symbol search path is:
srv*D:\Debug\DbgSymbols*http://msdl.microsoft.com/download/symbols;D:\Debug\
dumps\grau-test20-040127\sym

Microsoft (R) Windows Debugger Version 6.1.0017.2
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [D:\Debug\dumps\grau-test20-040127\MEMORY.DMP]
Kernel Dump File: Full address space is available

Symbol search path is:
srv*D:\Debug\DbgSymbols*http://msdl.microsoft.com/download/symbols;D:\Debug\
dumps\grau-test20-040127\sym
Executable search path is:
Windows 2000 Kernel Version 2195 (Service Pack 3) MP (2 procs) Free x86
compatible
Product: Server
Kernel base = 0x80400000 PsLoadedModuleList = 0x80483fa0
Debug session time: Tue Jan 27 18:32:06 2004
System Uptime: 0 days 2:46:59.484
Loading Kernel Symbols
…
…
Loading unloaded module list
…
Loading User Symbols
…
…
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

Use !analyze -v to get detailed debugging information.

BugCheck 24, {19025e, be3f16ac, be3f1304, bfef1501}

*** ERROR: Symbol file could not be found. Defaulted to export symbols for
SYMEVENT.SYS -
*** WARNING: Unable to verify checksum for StorageCommon.DLL
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
StorageCommon.DLL -
*** WARNING: Unable to verify checksum for StorageArchive.exe
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
StorageArchive.exe -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
MSVCRT.dll -
Probably caused by : IvdIFS_G.sys ( IvdIFS_G!IvdIrpGetBasicInfoBase+1ac )

Followup: MachineOwner

1: kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

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: be3f16ac
Arg3: be3f1304
Arg4: bfef1501

Debugging Details:

EXCEPTION_RECORD: be3f16ac – (.exr ffffffffbe3f16ac)
ExceptionAddress: bfef1501 (Ntfs!NtfsQueryBasicInfo+0x00000085)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000004
Attempt to read from address 00000004

CONTEXT: be3f1304 – (.cxr ffffffffbe3f1304)
eax=00000000 ebx=e3d490d8 ecx=00000000 edx=be3f1a4c esi=e3d49008
edi=be3f1a74
eip=bfef1501 esp=be3f1774 ebp=be3f181c iopl=0 nv up ei pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
Ntfs!NtfsQueryBasicInfo+85:
bfef1501 f6400402 test byte ptr [eax+0x4],0x2
ds:0023:00000004=??
Resetting default context

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from bfef0902 to bfef1501

STACK_TEXT:
be3f177c bfef0902 be3f1864 81237978 e3d490d8 Ntfs!NtfsQueryBasicInfo+0x85
be3f181c bfef1245 be3f1864 8135e948 81c03760
Ntfs!NtfsCommonQueryInformation+0x1fe
be3f1990 8041db79 81c03760 8135e948 be3f1a74
Ntfs!NtfsFsdQueryInformation+0xd7
be3f19a4 be12f25c 815daf00 8135eab4 00000000 nt!IopfCallDriver+0x35
be3f19dc be12f2de 81c03760 81237978 be3f1a4c
IvdIFS_G!IvdIrpGetBasicInfoBase+0x1ac [ivdifs_myirp.c @ 212]
be3f19f4 be12551e 81237978 81c03760 be3f1a4c
IvdIFS_G!IvdIrpGetBasicInfo+0x2e [ivdifs_myirp.c @ 241]
be3f1a80 be2d43c8 81237978 00000001 be3f1acc
IvdIFS_G!IvdFioQueryStandardInfo+0x1be [ivdifs_fastio.c @ 274]
WARNING: Stack unwind information not available. Following frames may be
wrong.
be3f1aa4 8049bee9 81237978 00000001 be3f1acc SYMEVENT+0x23c8
be3f1afc 804d34b0 81237978 be3f1b9c 00000000 nt!FsRtlGetFileSize+0x35
be3f1ba4 8043badc e37eb3d0 be3f1c98 00000000 nt!MmExtendSection+0xf6
be3f1cc8 804cb231 be3f1d1c 000f0007 00000000 nt!MmCreateSection+0xa16
be3f1d40 80465ee9 0102d25c 000f0007 00000000 nt!NtCreateSection+0x129
be3f1d40 77f88293 0102d25c 000f0007 00000000 nt!KiSystemService+0xc9
0102d200 7c586f1e 0102d25c 000f0007 00000000 ntdll!NtCreateSection+0xb
0102d260 1003792b 000000a8 00000000 00000004
KERNEL32!CreateFileMappingW+0xd7
0102d4a8 004079e9 0052c6d0 01a16560 00000000
StorageCommon!CVaultParameters::GetVaultType+0x326e
0102ff40 00408b72 01cff78c 00000000 00528870
StorageArchive!CParametersMessage::operator=+0x3508
0102ff80 780060ce 00cff78c 00000000 00000000
StorageArchive!CParametersMessage::operator=+0x4691
0102ffb4 7c57b382 00528870 00000000 00000000 MSVCRT!beginthreadex+0xb2
0102ffec 00000000 78006073 00528870 00000000 KERNEL32!BaseThreadStart+0x52

FOLLOWUP_IP:
IvdIFS_G!IvdIrpGetBasicInfoBase+1ac
be12f25c 8945dc mov [ebp-0x24],eax

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: IvdIFS_G!IvdIrpGetBasicInfoBase+1ac

MODULE_NAME: IvdIFS_G

IMAGE_NAME: IvdIFS_G.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3fd474c2

STACK_COMMAND: .cxr ffffffffbe3f1304 ; kb

BUCKET_ID: 0x24_IvdIFS_G!IvdIrpGetBasicInfoBase+1ac

Followup: MachineOwner

Code for rolling the IRP:

memset(pFileBasicInfo, 0, sizeof(FILE_BASIC_INFORMATION));

// Initialize the event
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

// Allocate an irp for this request. \todo This could also come from a
// private pool, for instance.
irp = IoAllocateIrp(DeviceObject->StackSize, FALSE);

if (!irp) {
// Failure!
return STATUS_NO_MEMORY;
};

// Build the IRP’s main body
irp->AssociatedIrp.SystemBuffer = pFileBasicInfo;
irp->UserEvent = &event;
irp->UserIosb = &IoStatusBlock;
irp->Tail.Overlay.Thread = PsGetCurrentThread();
irp->Tail.Overlay.OriginalFileObject = FileObject;
irp->RequestorMode = KernelMode;
irp->Flags = (IRP_SYNCHRONOUS_API|IRP_BUFFERED_IO);

// Set up the I/O stack location.
ioStackLocation = IoGetNextIrpStackLocation(irp);
ioStackLocation->MajorFunction = IRP_MJ_QUERY_INFORMATION;
ioStackLocation->DeviceObject = DeviceObject;
ioStackLocation->FileObject = FileObject;
ioStackLocation->Parameters.QueryFile.Length =
sizeof(FILE_BASIC_INFORMATION);
ioStackLocation->Parameters.QueryFile.FileInformationClass =
FileBasicInformation;

// Set the completion routine.
IoSetCompletionRoutine(irp, IvdIrpGetInfoCompl, 0, TRUE, TRUE, TRUE);

ntStatus = IoCallDriver(DeviceObject, irp);
if (ntStatus==STATUS_PENDING) {
KeWaitForSingleObject(&event, Executive, KernelMode, FALSE, NULL);
ntStatus = IoStatusBlock.Status;
};

–

Nick Ryan
Microsoft MVP for DDK

OSR_Community_User · February 4, 2004, 8:44am

You mentioned the IRP_PAGING_IO flag. My interpretation was that his
problem happend in the FastIO path. So: is there a way to detect
“PAGING_IO” in the FastIO path ?

You won’t get paging i/o in fast path. Fast path are for requests that
can be serviced by cache manager or other non-blocking objects.

OSR_Community_User · February 5, 2004, 12:49pm

Lars,

(I’m responding back to this earlier thread because I wanted the crash
information.)

Nick is correct that the fact that this is a recursive operation is not
your problem.

Is this crash from a machine running Windows 2000? Also, is this
FileObject a stream file object (the flag FO_STREAM_FILE 0x100 will be
set in the FileObjects->Flags field)?

If the answer to both of these questions is “Yes”, then your problem is
that NTFS did not support querying information for stream file objects
in Windows 2000. In fact, NTFS didn’t expect to get query information
requests for these types of file objects, so one of the needed internal
data structures is NULL and you are bugchecking as NTFS tries to access
this field. This support was added to NTFS in Windows XP.

Thanks,
Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nick Ryan
Sent: Tuesday, February 03, 2004 9:25 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Bugcheck NTFS_FILE_SYSTEM (24)

From the looks of the stack, you’re querying for basic info while
processing a get file size request with the IRP_PAGING_IO flag set (Mm
pre-acquires filesystem locks prior to extending a section). You’re very
restricted in the type of requests you can fire off to the underlying
filesystem while blocking a paging I/O request, due to locking issues.
It may be safe to query for basic info, but as a rule of thumb I would
not do this.

Having said that, your immediate issue may be different, since the
situation I just described would most likely result in a deadlock, not a
crash.

Lars Diehl wrote:

Hi all,

I’ve got a very strange BSOD one a machine our filter driver is
running on.
I’ve just started supporting kernel mode software, so please don’t
pick on me in case the following assumptions arr wrong…

This is what (I think) I found out:

Our filter driver provides HSM functinality. The
IvdFioQueryStandardInfo function first calls the lower level fastio
routine and then checks the attributes of the file in question. This
is done by creating an IRP (IRP_MJ_QUERY_INFORMATION, BasicInfo) and
sending it down to NTFS. Usually this code works, but under certain
circumstances (when called by
StorageArchive.exe) sometimes this BSOD occurs. I’ve checked the code
that creates the IRP serveral times against the samples in this list,
but I couldn’t find what’s wrong.

What seems strange:

The return adress of 8041db79 on the stack for
Ntfs!NtfsFsdQueryInformation be3f1990 8041db79 81c03760 8135e948
be3f1a74
Ntfs!NtfsFsdQueryInformation+0xd7

Strange parameters in on the stack for nt!IopfCallDriver
be3f19a4 be12f25c 815daf00 8135eab4 00000000 nt!IopfCallDriver+0x35

1st parameter should be the device object which seems to be fine:

1: kd> !object 815daf00
Object: 815daf00 Type: (820807a0) Device
ObjectHeader: 815daee8
HandleCount: 0 PointerCount: 1

2nd parameter is supposed to be the irp. (which seems to be wrong)
1: kd> !irp 8135eab4
IRP signature does not match, probably not an IRP

When I check the irp in my local parameters it has a differnt adress
and can be displayed:
1: kd> !irp 8135e948
Irp is active with 8 stacks 8 is current (= 0x8135eab4) No Mdl Irp
count = be3f1a4c Thread 8168caa0: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

>[5, 0] 0 e0 81c03760 81237978 be12f020-00000000 Success Error
Cancel

\FileSystem\Ntfs IvdIFS_G!IvdIrpGetInfoCompl
Args: 00000028 00000004 00000000 00000000

Does anybody have an idea what’s wrong on this system ?

Thanks for any help in advance,

Lars

Debugger output:

Symbol search path is:
srv*D:\Debug\DbgSymbols*http://msdl.microsoft.com/download/symbols;D:\
Debug\
dumps\grau-test20-040127\sym

Microsoft (R) Windows Debugger Version 6.1.0017.2 Copyright (c)
Microsoft Corporation. All rights reserved.

Loading Dump File [D:\Debug\dumps\grau-test20-040127\MEMORY.DMP]
Kernel Dump File: Full address space is available

Symbol search path is:
srv*D:\Debug\DbgSymbols*http://msdl.microsoft.com/download/symbols;D:\
Debug\
dumps\grau-test20-040127\sym
Executable search path is:
Windows 2000 Kernel Version 2195 (Service Pack 3) MP (2 procs) Free
x86 compatible
Product: Server
Kernel base = 0x80400000 PsLoadedModuleList = 0x80483fa0 Debug session

time: Tue Jan 27 18:32:06 2004 System Uptime: 0 days 2:46:59.484
Loading Kernel Symbols

…
…

…
Loading unloaded module list
…
Loading User Symbols

…
…

…
**********************************************************************
******
***
*
*
* Bugcheck Analysis
*
*
*
**********************************************************************
******
***

Use !analyze -v to get detailed debugging information.

BugCheck 24, {19025e, be3f16ac, be3f1304, bfef1501}

*** ERROR: Symbol file could not be found. Defaulted to export
symbols for SYMEVENT.SYS -
*** WARNING: Unable to verify checksum for StorageCommon.DLL
*** ERROR: Symbol file could not be found. Defaulted to export
symbols for StorageCommon.DLL -
*** WARNING: Unable to verify checksum for StorageArchive.exe
*** ERROR: Symbol file could not be found. Defaulted to export
symbols for StorageArchive.exe -
*** ERROR: Symbol file could not be found. Defaulted to export
symbols for MSVCRT.dll - Probably caused by : IvdIFS_G.sys (
IvdIFS_G!IvdIrpGetBasicInfoBase+1ac )

Followup: MachineOwner

1: kd> !analyze -v
**********************************************************************
******
***
*
*
* Bugcheck Analysis
*
*
*
**********************************************************************
******
***

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: be3f16ac
Arg3: be3f1304
Arg4: bfef1501

Debugging Details:

EXCEPTION_RECORD: be3f16ac – (.exr ffffffffbe3f16ac)
ExceptionAddress: bfef1501 (Ntfs!NtfsQueryBasicInfo+0x00000085)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000004
Attempt to read from address 00000004

CONTEXT: be3f1304 – (.cxr ffffffffbe3f1304) eax=00000000
ebx=e3d490d8 ecx=00000000 edx=be3f1a4c esi=e3d49008
edi=be3f1a74
eip=bfef1501 esp=be3f1774 ebp=be3f181c iopl=0 nv up ei pl zr
na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
Ntfs!NtfsQueryBasicInfo+85:
bfef1501 f6400402 test byte ptr [eax+0x4],0x2
ds:0023:00000004=??
Resetting default context

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x24

LAST_CONTROL_TRANSFER: from bfef0902 to bfef1501

STACK_TEXT:
be3f177c bfef0902 be3f1864 81237978 e3d490d8
Ntfs!NtfsQueryBasicInfo+0x85 be3f181c bfef1245 be3f1864 8135e948
81c03760 Ntfs!NtfsCommonQueryInformation+0x1fe
be3f1990 8041db79 81c03760 8135e948 be3f1a74
Ntfs!NtfsFsdQueryInformation+0xd7
be3f19a4 be12f25c 815daf00 8135eab4 00000000 nt!IopfCallDriver+0x35
be3f19dc be12f2de 81c03760 81237978 be3f1a4c
IvdIFS_G!IvdIrpGetBasicInfoBase+0x1ac [ivdifs_myirp.c @ 212]
be3f19f4 be12551e 81237978 81c03760 be3f1a4c
IvdIFS_G!IvdIrpGetBasicInfo+0x2e [ivdifs_myirp.c @ 241] be3f1a80
be2d43c8 81237978 00000001 be3f1acc
IvdIFS_G!IvdFioQueryStandardInfo+0x1be [ivdifs_fastio.c @ 274]
WARNING: Stack unwind information not available. Following frames may
be wrong.
be3f1aa4 8049bee9 81237978 00000001 be3f1acc SYMEVENT+0x23c8 be3f1afc
804d34b0 81237978 be3f1b9c 00000000 nt!FsRtlGetFileSize+0x35
be3f1ba4 8043badc e37eb3d0 be3f1c98 00000000 nt!MmExtendSection+0xf6
be3f1cc8 804cb231 be3f1d1c 000f0007 00000000 nt!MmCreateSection+0xa16
be3f1d40 80465ee9 0102d25c 000f0007 00000000 nt!NtCreateSection+0x129
be3f1d40 77f88293 0102d25c 000f0007 00000000 nt!KiSystemService+0xc9
0102d200 7c586f1e 0102d25c 000f0007 00000000 ntdll!NtCreateSection+0xb

0102d260 1003792b 000000a8 00000000 00000004
KERNEL32!CreateFileMappingW+0xd7
0102d4a8 004079e9 0052c6d0 01a16560 00000000
StorageCommon!CVaultParameters::GetVaultType+0x326e
0102ff40 00408b72 01cff78c 00000000 00528870
StorageArchive!CParametersMessage::operator=+0x3508
0102ff80 780060ce 00cff78c 00000000 00000000
StorageArchive!CParametersMessage::operator=+0x4691
0102ffb4 7c57b382 00528870 00000000 00000000 MSVCRT!beginthreadex+0xb2

0102ffec 00000000 78006073 00528870 00000000
KERNEL32!BaseThreadStart+0x52

FOLLOWUP_IP:
IvdIFS_G!IvdIrpGetBasicInfoBase+1ac
be12f25c 8945dc mov [ebp-0x24],eax

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: IvdIFS_G!IvdIrpGetBasicInfoBase+1ac

MODULE_NAME: IvdIFS_G

IMAGE_NAME: IvdIFS_G.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3fd474c2

STACK_COMMAND: .cxr ffffffffbe3f1304 ; kb

BUCKET_ID: 0x24_IvdIFS_G!IvdIrpGetBasicInfoBase+1ac

Followup: MachineOwner

Code for rolling the IRP:

memset(pFileBasicInfo, 0, sizeof(FILE_BASIC_INFORMATION));

// Initialize the event
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

// Allocate an irp for this request. \todo This could also come from
a
// private pool, for instance.
irp = IoAllocateIrp(DeviceObject->StackSize, FALSE);

if (!irp) {
// Failure!
return STATUS_NO_MEMORY;
};

// Build the IRP’s main body
irp->AssociatedIrp.SystemBuffer = pFileBasicInfo;
irp->UserEvent = &event;
irp->UserIosb = &IoStatusBlock;
irp->Tail.Overlay.Thread = PsGetCurrentThread();
irp->Tail.Overlay.OriginalFileObject = FileObject;
irp->RequestorMode = KernelMode;
irp->Flags = (IRP_SYNCHRONOUS_API|IRP_BUFFERED_IO);

// Set up the I/O stack location.
ioStackLocation = IoGetNextIrpStackLocation(irp);
ioStackLocation->MajorFunction = IRP_MJ_QUERY_INFORMATION;
ioStackLocation->DeviceObject = DeviceObject;
ioStackLocation->FileObject = FileObject;
ioStackLocation->Parameters.QueryFile.Length =
sizeof(FILE_BASIC_INFORMATION);
ioStackLocation->Parameters.QueryFile.FileInformationClass =
FileBasicInformation;

// Set the completion routine.
IoSetCompletionRoutine(irp, IvdIrpGetInfoCompl, 0, TRUE, TRUE,
TRUE);

ntStatus = IoCallDriver(DeviceObject, irp);
if (ntStatus==STATUS_PENDING) {
KeWaitForSingleObject(&event, Executive, KernelMode, FALSE, NULL);
ntStatus = IoStatusBlock.Status;
};

–

Nick Ryan
Microsoft MVP for DDK

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

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