Shadow Volume Problem with IoCreateFileSpecifyDeviceObjectHint

Hello All,

My filter driver is running at the Virtualization level and I am using the Shadow Volume technique where I redirect the creates to an alternate volume and handle the file object above my layer and use the real file object below my layer. I’ve run into an issue where a driver above me is calling IoCreateFileSpecifyDeviceObjectHint with an object attributes that has the RootDirectory set. I get called to do a create on the root directory object, but I don?t get called for the actual create using that object attributes because I see the call stack shown below first. I?m not getting the chance to redirect correctly because something else is using the objects before issuing the call down to me.

I see the dreaded 0x24 blue screen because the file object that is being referenced is mine, but there are no calls to my driver to get the information, instead the ntfs objects are assumed to be in the fscontext.

Here is the callstack that I am seeing when the crash happens:

fffff880012ea911 : fffffa8001e8ed30 fffffa8002dd4b70 fffff880034f5e50 fffff880034f5ea0 : Ntfs!NtfsFindStartingNode+0xdc fffff88001253a3d : fffffa8001e8ed30 fffffa8002dd4b70 fffff8800303df20 0000000000000000 : Ntfs!NtfsCommonCreate+0x3e1
fffff80002678cb7 : fffff8800303de90 0000000000000000 0000000000000000 0000000000000000 : Ntfs!NtfsCommonCreateCallout+0x1d fffff80002678c78 : 0000000000000000 0000000000000000 fffff880034f6000 fffff8000268d032 : nt!KxSwitchKernelStackCallout+0x27
fffff8000268d032 : 0000000000000000 0000000000000002 fffffa8001dd6960 fffffa8000000000 : nt!KiSwitchKernelStackContinue fffff880012541bf : fffff88001253a20 fffff88001253020 0000000000000000 fffff880012f4f00 : nt!KeExpandKernelStackAndCalloutEx+0x2a2
fffff880012ed99c : 0000000000000000 0000000000000000 fffffa80034816d8 fffffa8002dd4b70 : Ntfs!NtfsCommonCreateOnNewStack+0x4f fffff8000297abe5 : fffffa8001bd2030 fffffa8002dd4b70 fffffa8000f64900 fffffa8001d31c58 : Ntfs!NtfsFsdCreate+0x1ac
fffff80002977212 : fffffa8001a3d3c0 fffffa8000000000 fffffa8003481520 fffff88000000000 : nt!IopParseDevice+0x5a5 fffff800029786a6 : ffffffff80000d18 fffffa8003481520 fffffa8000cbd040 fffffa8000cd8790 : nt!ObpLookupObjectName+0x312
fffff80002979fac : 0000000000000000 0000000000000000 fffffa8000000000 fffffa8000000201 : nt!ObOpenObjectByName+0x306 fffff8000292172b : fffff8800303e6d8 0000000000100020 fffff8800303e668 fffff8800303e658 : nt!IopCreateFile+0x2bc
fffff800028f90a5 : fffff8800303e658 fffff8800303e6d8 0000000000100020 fffff8800303e668 : nt!IoCreateFileEx+0xfb fffff88005a9a177 : 0000000000000000 fffff8800303e669 0000000000000000 fffffa8001bd2030 : nt!IoCreateFileSpecifyDeviceObjectHint+0xe5
fffff88005b29c3f : ffffffff80000d18 0000000000000000 fffffa8001d30dd0 0000000000000000 : klif+0x11177 fffff88005b283a0 : ffffffff80000e5c 000000000000011c 0000000000000001 0000000000000000 : klif+0xa0c3f
fffff80002a65317 : fffffa800300adb0 fffffa800300adb0 fffffa800300adb0 00000000000007ff : klif+0x9f3a0 fffff80002a65715 : 0000000000000010 0000000000000000 0000000000000010 0000000000010206 : nt!IopLoadDriver+0xa07
fffff8000268a851 : fffff80000000000 ffffffff80000dec fffff80002a656c0 fffff8000281e2d8 : nt!IopLoadUnloadDriver+0x55 fffff80002917e6a : 0000000125b926c3 fffffa8001fd0b50 0000000000000080 fffffa8000cbd040 : nt!ExpWorkerThread+0x111

My questions are:

  1. Is is legal to call the IoCreateFileSpeciyDeviceObjectHint from a mini-filter with a root directory set?
  2. I thought that even if the call was made the filter manager layers would make sure that I was called for all operations, allowing me to manage the file object correctly, since I am lower in the stack than the driver that is issuing the call.

Any insight on this would be welcome.