Any idea about the following bug check and Assert?

ayush_gupta · December 26, 2006, 9:33am

Hi!
I am testing my minifilter on a Checked build version of Windows XP SP2.
I am getting the following ASSERT failed.

Assertion failed: No correspondence btwn file and device in irp((IrpSp->FileObject->Vpb == NULL) && ((IrpSp->FileObject->DeviceObject != NULL) && (IrpSp->FileObject->DeviceObject->Vpb != NULL) && (IrpSp->DeviceObject == IrpSp->FileObject->DeviceObject->Vpb->DeviceObject))) || ((IrpSp->FileObject->Vpb != NULL) && (IrpSp->DeviceObject == IrpSp->FileObject->Vpb->DeviceObject)) || (!FlagOn( Vcb->VcbState, VCB_STATE_VOLUME_MOUNTED ))
*** Source File: d:\xpsprtm\base\fs\ntfs\strucsup.c, line 6621

When i ignore the fail in my debugger, it finally gives a bug check:

*** Fatal System Error: 0x00000023
(0x0011012F,0x00000705,0x00000000,0x00000000)

Following is the STACK TRACE:

MODULE_NAME: Fastfat

FAULTING_MODULE: 80800000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 411089e0

DEFAULT_BUCKET_ID: WRONG_SYMBOLS

BUGCHECK_STR: 0x23

LAST_CONTROL_TRANSFER: from 8082f840 to 808b8300

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
f7c475d8 8082f840 00000003 00000000 00000705 nt!DbgBreakPointWithStatus+0x4
f7c479b8 8082fdd1 00000023 0011012f 00000705 nt!KeRegisterBugCheckReasonCallback+0x804
f7c479d8 f6afe829 00000023 0011012f 00000705 nt!KeBugCheckEx+0x1b
f7c479fc f6b05233 86dddbc0 f7c47a24 f7c47a38 Fastfat+0x8829
f7c47a5c f6b0510e 86dc41d0 8691ba78 86b6e128 Fastfat+0xf233
f7c47aa0 8081fa41 86b6e128 8691ba78 86ddfdd0 Fastfat+0xf10e
f7c47ad4 8081fa41 86ddfdd0 8691ba78 808b9ffc nt!IoBuildPartialMdl+0x15b
f7c47b14 f75c3970 f7c47b34 86e6bac0 00000000 nt!IoBuildPartialMdl+0x15b
f7c47b54 f75f65d4 00000000 86b6c6d8 862e3390 fltmgr!FltPerformSynchronousIo+0x1ca
f7c47b70 f5493c4b 86b6c6d8 86dddbc0 f7c47bfc fltmgr!FltQueryInformationFile+0xf6
f7c47c34 f549673b 86bb2f5c 86b6c6d8 862e23e0 AlphaSecure!__BmWriteToRMDFile+0x2db [c:\alphasecure\backupmgr\backupmgr.c @ 204]
f7c47d28 f54965ad 86bb2f5c 86bfb124 862e3698 AlphaSecure!__ASProcessCallbackData+0x10b [c:\alphasecure\minifilter\alphasecure.c @ 1326]
f7c47d64 f760e6ac 86e00218 86bb2f5c 86b6c6d8 AlphaSecure!__ASPreCallbackWorkItemRoutine+0x1ad [c:\alphasecure\minifilter\alphasecure.c @ 1214]
f7c47d80 808c9e45 86e00218 00000000 86fac640 fltmgr!FltGetDestinationFileNameInformation+0x3d92
f7c47dac 809c996e 86e00218 00000000 00000000 nt!ExQueueWorkItem+0x28b
f7c47ddc 808d8f22 808c9d36 00000001 00000000 nt!PsRemoveCreateThreadNotifyRoutine+0x368
00000000 00000000 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x802

This is the exact line in code that is being pointed to:
Status = FltQueryInformationFile( pInstance,
Globals.pFNameFileObject,
&PositionInfo,
sizeof( FILE_POSITION_INFORMATION ),
FilePositionInformation,

Any idea what the problem may be?

Thanks!
Ayush Gupta

Don_Burn_1 · December 26, 2006, 9:40am

Well you have the wrong symbols which does not help at all. Fix the
symbols and figure out what routine in FastFat is ASSERT’ing, the go read
the source (since it is in the IFS kit and the WDK) and you should be able
to figure this out.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

wrote in message news:xxxxx@ntfsd…
> Hi!
> I am testing my minifilter on a Checked build version of Windows XP SP2.
> I am getting the following ASSERT failed.
>
> Assertion failed: No correspondence btwn file and device in
> irp((IrpSp->FileObject->Vpb == NULL) && ((IrpSp->FileObject->DeviceObject
> != NULL) && (IrpSp->FileObject->DeviceObject->Vpb != NULL) &&
> (IrpSp->DeviceObject ==
> IrpSp->FileObject->DeviceObject->Vpb->DeviceObject))) ||
> ((IrpSp->FileObject->Vpb != NULL) && (IrpSp->DeviceObject ==
> IrpSp->FileObject->Vpb->DeviceObject)) || (!FlagOn( Vcb->VcbState,
> VCB_STATE_VOLUME_MOUNTED ))
> Source File: d:\xpsprtm\base\fs\ntfs\strucsup.c, line 6621
>
> When i ignore the fail in my debugger, it finally gives a bug check:
>
> Fatal System Error: 0x00000023
> (0x0011012F,0x00000705,0x00000000,0x00000000)
>
> Following is the STACK TRACE:
>
> MODULE_NAME: Fastfat
>
> FAULTING_MODULE: 80800000 nt
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 411089e0
>
> DEFAULT_BUCKET_ID: WRONG_SYMBOLS
>
> BUGCHECK_STR: 0x23
>
> LAST_CONTROL_TRANSFER: from 8082f840 to 808b8300
>
> STACK_TEXT:
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> f7c475d8 8082f840 00000003 00000000 00000705
> nt!DbgBreakPointWithStatus+0x4
> f7c479b8 8082fdd1 00000023 0011012f 00000705
> nt!KeRegisterBugCheckReasonCallback+0x804
> f7c479d8 f6afe829 00000023 0011012f 00000705 nt!KeBugCheckEx+0x1b
> f7c479fc f6b05233 86dddbc0 f7c47a24 f7c47a38 Fastfat+0x8829
> f7c47a5c f6b0510e 86dc41d0 8691ba78 86b6e128 Fastfat+0xf233
> f7c47aa0 8081fa41 86b6e128 8691ba78 86ddfdd0 Fastfat+0xf10e
> f7c47ad4 8081fa41 86ddfdd0 8691ba78 808b9ffc nt!IoBuildPartialMdl+0x15b
> f7c47b14 f75c3970 f7c47b34 86e6bac0 00000000 nt!IoBuildPartialMdl+0x15b
> f7c47b54 f75f65d4 00000000 86b6c6d8 862e3390
> fltmgr!FltPerformSynchronousIo+0x1ca
> f7c47b70 f5493c4b 86b6c6d8 86dddbc0 f7c47bfc
> fltmgr!FltQueryInformationFile+0xf6
> f7c47c34 f549673b 86bb2f5c 86b6c6d8 862e23e0
> AlphaSecure!__BmWriteToRMDFile+0x2db
> [c:\alphasecure\backupmgr\backupmgr.c @ 204]
> f7c47d28 f54965ad 86bb2f5c 86bfb124 862e3698
> AlphaSecure!__ASProcessCallbackData+0x10b
> [c:\alphasecure\minifilter\alphasecure.c @ 1326]
> f7c47d64 f760e6ac 86e00218 86bb2f5c 86b6c6d8
> AlphaSecure!__ASPreCallbackWorkItemRoutine+0x1ad
> [c:\alphasecure\minifilter\alphasecure.c @ 1214]
> f7c47d80 808c9e45 86e00218 00000000 86fac640
> fltmgr!FltGetDestinationFileNameInformation+0x3d92
> f7c47dac 809c996e 86e00218 00000000 00000000 nt!ExQueueWorkItem+0x28b
> f7c47ddc 808d8f22 808c9d36 00000001 00000000
> nt!PsRemoveCreateThreadNotifyRoutine+0x368
> 00000000 00000000 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x802
>
> This is the exact line in code that is being pointed to:
> Status = FltQueryInformationFile( pInstance,
> Globals.pFNameFileObject,
> &PositionInfo,
> sizeof( FILE_POSITION_INFORMATION ),
> FilePositionInformation,
>
>
> Any idea what the problem may be?
>
> Thanks!
> Ayush Gupta
>

ayush_gupta · January 5, 2007, 10:19am

Hi!
There is no ASSERT of this sort mentioned anywhere in the fastfat sample in the IFS kit.
Also, whenever the bug check comes, the system points it to FatDecodeFileObject routine in the FastFat driver…

Does anyone have any idea about the ASSERT that i have mentioned?
Maybe after knowing exactly what this ASSERT means, i can identify the problem in my code…

Thanks!
Ayush Gupta

ayush_gupta · January 5, 2007, 10:26am

Hi!
Now i am facing the same ASSERT for Ntfs also. The exact message that i get in the debugger is:

*** Assertion failed: No correspondence btwn file and device in irp((IrpSp->FileObject->Vpb == NULL) && ((IrpSp->FileObject->DeviceObject != NULL) && (IrpSp->FileObject->DeviceObject->Vpb != NULL) && (IrpSp->DeviceObject == IrpSp->FileObject->DeviceObject->Vpb->DeviceObject))) || ((IrpSp->FileObject->Vpb != NULL) && (IrpSp->DeviceObject == IrpSp->FileObject->Vpb->DeviceObject)) || (!FlagOn( Vcb->VcbState, VCB_STATE_VOLUME_MOUNTED ))
*** Source File: d:\xpsprtm\base\fs\ntfs\strucsup.c, line 6621

OSR_Community_User · January 5, 2007, 11:18am

Someone is sending the wrong file object to NTFS - that’s the meaning of
the assert. Basically, NTFS is saying “hey, this file object isn’t
associated with the device object.”

You could trigger this, for instance, if you passed some other FSDs FO
into NTFS. You could also do this if you passed an FO against one volume
to the device object of a different volume.

Since you have a crash and/or the debugger available, did you look at
the values to see which of the conditions failed?

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

ayush_gupta · January 6, 2007, 2:28am

Hi Tony!
Thanks for the reply!
Actually, i see this bug check when i try to open “My Computer”.
I have 4 volumes.
The system bug checks when the IRP_MJ_CREATE for \Device\HarddiskVolume4 comes.
In my worker thread i issue a FltQueryInformationFile on a file on c: that is used for logging purpose. I use the same instance pointer that i get from the Create callback routine.

The above scenario does not come for any other volume.

Any idea y this is happening?

Ayush Gupta
Calsoft Pvt. Ltd.

Lyndon_J_Clarke-2 · January 6, 2007, 8:20am

I think, from you description, perhaps all is clear.

You have opened a file on C: drive which you use for logging purposes so you
have some FileObject for this file on C: drive. You receive IRP_MJ_CREATE
callback for some other volume. You call FltQueryInformationFile passing the
instance from the IRP_MJ_CREATE callback and the FileObject for the file on
the C: drive. So filter manager sends IRP_MJ_CREATE to the device object for
the other volume - not C: - with the FileObject on the volume known as C:
… exact as Mr Mason has said.

wrote in message news:xxxxx@ntfsd…
> Hi Tony!
> Thanks for the reply!
> Actually, i see this bug check when i try to open “My Computer”.
> I have 4 volumes.
> The system bug checks when the IRP_MJ_CREATE for \Device\HarddiskVolume4
> comes.
> In my worker thread i issue a FltQueryInformationFile on a file on c: that
> is used for logging purpose. I use the same instance pointer that i get
> from the Create callback routine.
>
> The above scenario does not come for any other volume.
>
> Any idea y this is happening?
>
> Ayush Gupta
> Calsoft Pvt. Ltd.
>
>

ayush_gupta · January 6, 2007, 11:36pm

Hi!
Thanks everybody…
Actually Lyndon identified it correctly…
I had corrected this error but forgot to post the reply for the same…
Thanks once again…

Ayush Gupta