VCB in RelatedFileObject is NULL

NTFSD
1

Hi All,

This is my first post here so please be gentle!

I am writing an FSD implemenation for a propietary file system…mainly for the learning experience. I am using fastfat, romfs and Rajeev’s NT FS Internals FSD implemenations as examples to write my one. So far it’s going well and I am having lots fun (and lots of BSODs!).

I have written the IRP_MJ_CREATE distpatch routine following the example from the fastfat FSD implemenation available from the WDK 7600. It works fine in most scenarios and I can load my driver and browse the file system, open handles to files, etc.
I am now writting support for relative open operations but find that, while the FCB structure I pull out of the FsContext field from the related file object seems valid, the VCB pointer I have within the FCB it is NULL. I can make the related VCB point to the VCB of the file object being created and the rest of the routine works fine… but I can’t access that VCB directly from the related object.

Any ideas?

I am sorry if this is a silly question… this is my first go at writing drivers. I searched the previous posts but I coudn’t find any answers there.

Thanks.

2

Let me see if I got it … So you have FO1, already opened. Then you are
trying to open FO2 relative to FO1 and what you are seeing is that
FO1->FsContext is valid (pointing to a valid FCB structure for your
filesystem, FCB1) but that inside FCB1 you have a member pointer to your VCB
(FCB1->VCB) which is NULL ?

Thanks,
Alex.

3

Hi Alex,

Yes, that’s a lot clearer to read!

The fastfat implementation does the something along the following, I am doing it in pretty much the same way at the moment:

//Get the type of open and reference the VCB, FCB and CCB from the related object
TypeOfOpen = FatDecodeFileObject( RelatedFileObject,
&RelatedVcb,
&RelatedDcb,
&RelatedCcb );

//…removed some irrelevant lines for clarity

ASSERT( Vcb == RelatedVcb );

In my implementation it fails the assetion above.

Thanks

4

Well, maintaining the FCB is the file systems’ responsibility (well, at
least for the fields outside the header (FSRTL_ADVANCED_FCB_HEADER; your FCB
does start with an FSRTL_ADVANCED_FCB_HEADER, right?), which are used by
other parts of the system as well). The FCB->VCB is therefore something your
file system must populate and maintain. This is good because it simplifies
things quite a bit since the FCB->VCB must be set and cleared in your code,
which is usually easier to debug.

I would start debugging this by adding some ASSERTs that you never have
complete an IRP_MJ_CREATE with a NULL ((PFCB)FsContext)->VCB (so that you
are certain that all FILE_OBJECTs you own are properly set up and never have
a NULL VCB pointer). If this doesn’t yield any case you might have missed I
would then add a write breakpoint in windbg on (PFCB)(FO1->FsContext)->VCB
and see where the VCB pointer gets cleared.

Thanks,
Alex.

5

Thanks Alex, that makes a lot of sense.
I had added a few debug outputs to see if the VCB was being freed while there were still some references to it but that didn’t show anything wrong.
I will the ASSERTs you suggest and see if that brings up anything.

Thanks for the quick reply again. Very much appreciated.

6

I have now sorted it. I had managed to mix up the romfs and fastfat implementations… the romfs FCB structure doesn’t have an VCB and while using some of the Create procedures of romfs as an example I forgot to update the pointer to the VCB in my FCB in one of the Create paths.

Thanks for the help! Now I can move on and play with the read routines!

E.