[OSR-DETECTED-SPAM] Re: Shadow Volume Problem with IoCreateFileSpecifyDeviceObjectHint

Let me see if I got this right. The filter above yours is a minifilter ? It is illegal for a minifilter to call IoCreateFileSpecifyDeviceObjectHint, because it will violate layering.

Basically, this is a layering violation of some sort. The filter above yours targeted some IRP_MJ_CREATEs at you (at least your filter sees them) and other below you. A filter must be consistent in its use of layers.

FltMgr can’t really help you in this scenario because it doesn’t really know that you own the FILE_OBJECT or anything of that nature. Besides, it is possible that the caller of IoCreateFileSpecifyDeviceObjectHint bypasses FltMgr completely and calls directly into NTFS.

Does this make sense ?

Thanks,
Alex.
On Apr 23, 2013, at 6:18 AM, xxxxx@unidesk.com wrote:

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.

---

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

This looks like an interop issue with Kaspersky (klif.sys).

I certainly cannot tell from that stack trace if they are even operating as a mini-filter (note the call is from their DriverEntry function). Is there a reason you’ve concluded they are a mini-filter?

This doesn’t look like a deliberate attempt to violate layering - it sure sounds more like a bug in their assumptions. Perhaps someone from Kaspersky is on the lists here and can provide you with a private channel so you can figure this one out.

Good luck!

Tony
OSR

I’m running with Kaspersky version 10. The KLIF.sys is running at an altitude of 320400. And is showing up in the flmcinstances. I’m pretty sure they are a mini-filter.

You are correct that it would be an interop issue. But with no plugfest, I kind of at a loss for how to resolve the problem. Has any one heard why there has not been one scheduled in almost a year?

The Kaspersky driver (klif.sys) opens a handle to a directory by going through the *top* of the file system stack (and through your filter).

The problem arises because it then uses that handle to make a relative open which is targeted at the *bottom* of the file system stack (thus bypassing all filters - including the Filter Manager).

It is a bug in the Kaspersky driver because it assumes that there is no layered file system (like your virtualization filter) on the file system stack.

Regards,
Razvan

Then it would be a bug for them to be calling IoCreateFileSpecifyDeviceObjecHint* from a mini-filter in the first place. If Razvan’s description of what they’re doing is correct, it is indeed fundamentally broken.

Any filter that deliberately or accidentally bypasses other filters on the stack is broken.

You may need to list their product as being incompatible with yours for the time being. If you are in a situation where you MUST make this work, there are odious and generally unsupportable mechanisms for forcing it to work right, but I will not describe them on a public list - precisely because they are NOT things people should be doing.

The original model for Plugfest was that it was a community event for improving the stability of Windows in the face of file system filter drivers. It would seem that stability with filter drivers is no longer an urgent issue for Microsoft - perhaps because Plugfest was so successful - and the emphasis now seems to be more on late stage new OS version testing. While I could be wrong (and I’m happy to be corrected by someone at Microsoft in a position to speak definitively to this issue) were I to hazard a guess, I’d suggest they will probably have another one around some significant milestone for the next OS version, whatever that might be. The days of bi-annual Plugfests (which DID help with interop) seem to be gone at this point, unfortunately.

Tony
OSR

> This doesn’t look like a deliberate attempt to violate layering - it sure

sounds more like a bug in their assumptions.

Whether deliberate or not it is certainly bug to try to function at
multiple levels of the filter hierarchy without taking appropriate care.
You cannot issue a create to the top of the stack and then issue operations
based on the result to that half way down (or at the bottom) of the stack.

Of course the Microsoft FSDs could behave more politely when given the wrong
file object, particularly since this layered approach seems to be coming
quite popular.

Rod