Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

OSR Seminars


Go Back   OSR Online Lists > ntfsd
Welcome, Guest
You must login to post to this list
  Message 1 of 3  
06 Jan 18 00:04
Jorgen Lundman
xxxxxx@lundman.net
Join Date: 09 Nov 2017
Posts To This List: 14
IopIncrementVpbRefCount ?

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
  Message 2 of 3  
06 Jan 18 05:28
rod widdowson
xxxxxx@steadingsoftware.com
Join Date: 11 Sep 2006
Posts To This List: 865
IopIncrementVpbRefCount ?

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.
  Message 3 of 3  
10 Jan 18 01:56
Jorgen Lundman
xxxxxx@lundman.net
Join Date: 09 Nov 2017
Posts To This List: 14
IopIncrementVpbRefCount ?

Rod Widdowson <xxxxx@steadingsoftware.com> 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 | <xxxxx@lundman.net> Unix Administrator | +81 (0)90-5578-8500 Shibuya-ku, Tokyo | Japan
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntfsd list to be able to post.

All times are GMT -5. The time now is 00:28.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license