IRP_MJ_QUERY_INFORMATION with FsContext == NULL and FsContext2 != NULL

This is a question about what input parameters are legal in IRP_MJ_QUERY_INFORMATION. In other words, what can my FSD (a full FSD, not a filter) assume about the information passed to IRP_MJ_QUERY_INFORMATION. I hope that this is basic knowledge for experienced FSD developers…

I am investigating a bug check that occurred three times at our customer’s site. I currently only have kernel minidumps so I cannot check the values of all variables.

The crash has occurred during the processing of IRP_MJ_QUERY_INFORMATION. It is crashing when I try to access pfoFileObject->FsContext->CommonHeader. I can see that pfoFileObject->FsContext is NULL, which is obviously the cause of the Access Violation exception that I now have in my hands.

I am aware of the “unopened file object” issue. I know that FsContext can sometimes be NULL even though we are not in IRP_MJ_CREATE. This is particularly true for IoCreateStreamFile and IRP_MJ_CLEANUP. I have already prepared for “unopened file objects” in my FSD but now I suspect that I’ve done it incorrectly. Can you comment on the following code which I use to handle all “unopened file object” IRPs:

// Check for unopened FileObject requests.
//
if( pioslIrpSP->MajorFunction != IRP_MJ_CREATE &&
pioslIrpSP->FileObject &&
pioslIrpSP->FileObject->FsContext == NULL &&
pioslIrpSP->FileObject->FsContext2 == NULL )
{
// Special processing for an unopened FileObject that
// receives an IRP (typically Cleanup and Close).
//
if( pioslIrpSP->MajorFunction == IRP_MJ_CLEANUP ||
pioslIrpSP->MajorFunction == IRP_MJ_CLOSE )
{
(LET THESE SUCCEED)
}
else
{
(FAIL WITH STATUS_INVALID_DEVICE_REQUEST)
}
}

My concern is that I am overchecking. Should I omit the “&& pioslIrpSP->FileObject->FsContext2 == NULL” check? I guess any FileObject with FsContext == NULL should be treated as “unopened”, even if FsContext2 is not NULL?

Have you ever seen an IRP_MJ_QUERY_INFORMATION request where FileObject->FsContext is NULL but FileObject->FsContext2 is not NULL? Any known way of reproducing such case?

Another execution path that would lead to problems in my FSD is if FileObject itself is NULL in IRP_MJ_QUERY_INFORMATION. I assume that is not a legal situation and that my FSD can assume that FileObject is always non-NULL in IRP_MJ_QUERY_INFORMATION. Am I right??

(I know that FileObject can be NULL at least in IRP_MJ_SHUTDOWN and IRP_MJ_FILE_SYSTEM_CONTROL.)

Best regards,
Antti