IopIncrementVpbRefCount ?

NTFSD
1

Hello list!

Since I had great luck with last question, I thought I would push my
luck for another. At the moment I am running “ifstest.exe” to ensure the
correctness of my file system driver.

I can pass tests like that of:

FileSystemDeviceOpenTest
FileFullPathCreationTest
DirectoryFullPathCreationTest

BasicInformationTest
StandardInformationTest
NameInformationTest

So I feel confident those calls are “close” to “correct”, BUT, when I
try one of the these tests:

FileRelativePathCreationTest
DirectoryRelativePathCreationTest
TunnelTest

It BSODs quite early, and none of the IRP_MJ_CREATE calls have anything
but a NULL RelatedFileObject (which I would expect it to use, as it is
called RelativePath test, that’s what it’ll do, right?) so maybe it is
the very call to create a relative object that fails. The BSOD stack is:

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: 0000000000000000, Object type of the object whose reference count
is being lowered
Arg2: ffffce896610f210, Object whose reference count is being lowered
Arg3: 0000000000000007, Reserved
Arg4: 00000000ffffffc5, Reserved
The reference count of an object is illegal for the current
state of the object.

nt!KeBugCheckEx+0x107
nt!IopIncrementVpbRefCount+0xf7a91
nt!IopParseDevice+0x105c
nt!IopParseFile+0xc7
nt!ObpLookupObjectName+0x5b7
nt!ObOpenObjectByNameEx+0x1e0
nt!IopCreateFile+0x391
nt!NtCreateFile+0x79
nt!KiSystemServiceCopyEnd+0x13
ntdll!NtCreateFile+0x14
opcreatg!FileRelativePathCreationTest+0x254

Since it doesn’t involve my code in the stack, I am guessing I have not
set something up correctly. Perhaps the Vpb that it is trying to
increment. It seems Arg2 is not NULL though, from above. I do not really
do much with Vpb, at least compared to fastfat (which seems to copy and
swap it sometimes) Since the call before is ParseDevice, am I suppose to
set Vpb for the FILE_DEVICE_DISK I create perhaps?

The last call to my code is:

* query_information: FileStandardLinkInformation
file_standard_link_information
fsDispatcher: enter: major 5: minor 0: IRP_MJ_QUERY_INFORMATION
fsDeviceObject
* query_information: FileNameInformation (normalize 1)
file_name_information: remaining space 252 str.len 16 struct size 8
* file_name_information: partial name of ‘frelpath’ struct size 0x8 and
FileNameLength 0x10 Usedspace 0x10
KDTARGET: Refreshing KD connection

Any hints is appreciated!

Lund

2

I don’t have an answer for you, but how are you setting up FileObject->Vpb ?

That might give you something to look at. You should study FAT’s setting of
that field closely (particularly in the mount, dismount and PNP path). A I
recall there are some very odd edge cases where you may need to artificially
up the Vpb refcount and then down it again. But this feels more like
FileObject->RelatedFileObject->Vpb going weird.

3

Rod Widdowson wrote:
> I don’t have an answer for you, but how are you setting up FileObject->Vpb ?
>
> That might give you something to look at. You should study FAT’s setting
> of that field closely (particularly in the mount, dismount and PNP path).Â
> A I recall there are some very odd edge cases where you may need to
> artificially up the Vpb refcount and then down it again. But this feels
> more like FileObject->RelatedFileObject->Vpb going weird.

Yeah, I was doing the “same” setting as fastfat, minus the extra work it
did to swapVpb in deviceremove.

But it did turn out to be Vpb related (since the stack contained it). I
was indeed setting Vpb for each FileObject, so it was not NULL - but I was
just setting it to deviceObject->Vpb, when it is probably better to set it
to just the specific Vpb created for my volume.

I no longer BSOD, and can proceed to fix the testifs.exe errors.

I different errorcode is still progress!

Cheers,

Lund

–
Jorgen Lundman |
Unix Administrator | +81 (0)90-5578-8500
Shibuya-ku, Tokyo | Japan