LUAFV filter return x

Hi,
I wrote a mini-filter driver to provide virtualized namespace by redirecting all I/O access from drive C: to driver D: on Win 7 x64.
Everything worked just well if my filter driver(altitude 136000) was loaded above the LUAFV filter(Least User Authentication, altitude 135000, which was pre-installed by OS). However, if I changed the altitude of my driver to 132000 (which was below LUAFV), and if the application was an un-trusted 32-bit application, LUAFV randomly failed the file open operation on C:\ or other folders. I monitored the file open using ProcessMon and found the CreateFile(C:) in LUAFV returned 0xC01C0002 (STATUS_FLT_CONTEXT_ALREADY_DEFINED), while I was not setting any context in the IRP_CREATE pre/post callbacks.
I did some homework and found that LUAFV would redirecting the failed access to protect system directory, such as “\windows”, to “$APPDATA\VirtualStore” directory. Was my driver conflicted with it? why it will return STATUS_FLT_CONTEXT_ALREADY_DEFINED?
Any help will be highly appreciated!

I’d be inclined to pop in a filter (minispy works well) between LUA and you
and see what it thinks it is doing.

R

Rod, thanks for the advice, will try it and post back the result.

BTW, I have connected Windbg to the host machine and run ‘kb’ when luafv’s IRP?post create callback returned STATUS_FLT_CONTEXT_ALREADY_DEFINED:

luafv!LuafvPostCreate+0xad
fltmgr!FltpPerformPostCallbacks+0x368
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x39b
fltmgr!FltpCreate+0x2a9
nt!IopParseDevice+0x5a5
nt!ObpLookupObjectName+0x588
nt!ObOpenObjectByName+0x306
nt!IopCreateFile+0x2bc
nt!NtCreateFile+0x78
nt!KiSystemServiceCopyEnd+0x13

There are 1 strange thing that I could not figure out so far:

  1. in luafv!LuafvPostCreate, it allocated a stream context for the file object, and then called FltSetStreamHandleContext API. However, sometimes this API failed with STATUS_FLT_CONTEXT_ALREADY_DEFINED. It 's a little strange, since MSDN said a stream handle context was per-file object, for a new created file object in post IRP_CREATE callback, shouldn’t the context be NULL since no one has any chance to set it ? More strange part was that, for testing, I called FltGetStreamHandleContext in the very beginning of POST create callback, and indeed got a Non NULL stream context…