Hi Nick,
thanks for your help. Since I’m not very experienced in NT-kernel stuff
let me ask some more “stupid” questions:
-
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 ? -
I checked the code samples dealing with rolling own IRPs in this
list. The only difference to my code I was able to find the
IRP_BUFFERED_IO flag. In all code samples I found, the IRP_BUFFERD_IO
flag was not set. Does setting this flag have an influence on IoFreeIrp
? The documentation say that IRP_BUFFERED_IO means that
irp->AssociatedIrp.SystemBuffer is valid (which I thought it is) ?
Lars
-----Original Message-----
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:
> 1. The return adress of 8041db79 on the stack for
> Ntfs!NtfsFsdQueryInformation
> be3f1990 8041db79 81c03760 8135e948 be3f1a74
> Ntfs!NtfsFsdQueryInformation+0xd7
>
> 2. 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=17You are currently subscribed to ntfsd as: xxxxx@t-online.de
To unsubscribe send a blank email to xxxxx@lists.osr.com