Nick,
thanks for your help far. Things seem much clearer now.
During this discussion another option came to my mind: Would it be a good
idea for my filter to use FastIO (if available) to get file information
instead of rolling an IRP ?
WBR,
Lars
-----Ursprüngliche Nachricht-----
Von: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]Im Auftrag von Nick Ryan
Gesendet: Donnerstag, 5. Februar 2004 07:07
An: Windows File Systems Devs Interest List
Betreff: Re:[ntfsd] AW: Re:Bugcheck NTFS_FILE_SYSTEM (24)
-
Didn’t notice that this was a fast I/O call. You will see the paging
I/O flag on some categories of file size SET calls, however (which never
go through fast I/O). The effect this has is that it will cause FastFat
(and presumably NTFS) not to initiate caching on an uncached file object
in cases where it ordinarily would. -
IRP_BUFFERED_IO is yet another miserably undocumented constant. I
would just leave it out and see what happens.
xxxxx@t-online.de wrote:
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’revery
>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, nota
>crash.
>
>Lars Diehl wrote:
>
>
>>Hi all,
>>
>>I’ve got a very strange BSOD one a machine our filter driver isrunning 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. TheIvdFioQueryStandardInfo
>>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 thecode 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 adressand 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 ErrorCancel
>> \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) Freex86
>>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 exportsymbols for
>>SYMEVENT.SYS -
>>*** WARNING: Unable to verify checksum for StorageCommon.DLL
>>*** ERROR: Symbol file could not be found. Defaulted to exportsymbols for
>>StorageCommon.DLL -
>>*** WARNING: Unable to verify checksum for StorageArchive.exe
>>*** ERROR: Symbol file could not be found. Defaulted to exportsymbols for
>>StorageArchive.exe -
>>*** ERROR: Symbol file could not be found. Defaulted to exportsymbols 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 zrna 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 e3d490d8Ntfs!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 framesmay be
>>wrong.
>>be3f1aa4 8049bee9 81237978 00000001 be3f1acc SYMEVENT+0x23c8
>>be3f1afc 804d34b0 81237978 be3f1b9c 00000000nt!FsRtlGetFileSize+0x35
>>be3f1ba4 8043badc e37eb3d0 be3f1c98 00000000 nt!MmExtendSection+0xf6
>>be3f1cc8 804cb231 be3f1d1c 000f0007 00000000nt!MmCreateSection+0xa16
>>be3f1d40 80465ee9 0102d25c 000f0007 00000000
nt!NtCreateSection+0x129
>>be3f1d40 77f88293 0102d25c 000f0007 00000000 nt!KiSystemService+0xc9
>>0102d200 7c586f1e 0102d25c 000f0007 00000000ntdll!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 00000000MSVCRT!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 comefrom 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 athttps://www.osronline.com/article.cfm?id=17
>You are currently subscribed to ntfsd as: xxxxx@t-online.de
>To unsubscribe send a blank email to xxxxx@lists.osr.com
–
- 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@t-online.de
To unsubscribe send a blank email to xxxxx@lists.osr.com