Molly,
thanks for your help. Now were are getting somewhere…
“YES”, the system is W2k and “YES” the FO_STREAM_FILE flag is set.
Just for my understanding: The stack trace shows that the situation was
initiated by the function CreateFileMappingW(). Does this mean that the
application opened an NTFS file stream as memory mapped file with a name
like “file_name:stream_name” ?
Wbr,
Lars
-----Ursprüngliche Nachricht-----
Von: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]Im Auftrag von Molly Brown
Gesendet: Donnerstag, 5. Februar 2004 18:49
An: Windows File Systems Devs Interest List
Betreff: RE: [ntfsd] Bugcheck NTFS_FILE_SYSTEM (24)
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+0xd7Strange parameters in on the stack for nt!IopfCallDriver
be3f19a4 be12f25c 815daf00 8135eab4 00000000 nt!IopfCallDriver+0x351st 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: 12nd parameter is supposed to be the irp. (which seems to be wrong)
1: kd> !irp 8135eab4
IRP signature does not match, probably not an IRPWhen 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-00000000Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000Args: 00000000 00000000 00000000 00000000
>[5, 0] 0 e0 81c03760 81237978 be12f020-00000000 Success Error
Cancel\FileSystem\Ntfs IvdIFS_G!IvdIrpGetInfoCompl
Args: 00000028 00000004 00000000 00000000Does 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\symMicrosoft (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 availableSymbol 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: bfef1501Debugging 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 00000004CONTEXT: 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 contextDEFAULT_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+0x52FOLLOWUP_IP:
IvdIFS_G!IvdIrpGetBasicInfoBase+1ac
be12f25c 8945dc mov [ebp-0x24],eaxFOLLOWUP_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
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