FltUnregisterFilter() and PreCallback

Hello!
I’m faced with problem : when I unload my mimfilter (that attached to system volume C:) after call FltUnregisterFilter() I see PreCallback info (another words - PreCallback invoke) and after ~ 30 sec FltUnregisterFilter() exit.
Driver verifier not detect errors…
Why I see PreCallback till call FltUnregisterFilter()?

Do you use WorkItems in your filter (as in FltQueueGenericWorkItem()) ?

Thanks,
Alex

On Tue, Oct 13, 2015 at 6:28 AM, wrote:

> Hello!
> I’m faced with problem : when I unload my mimfilter (that attached to
> system volume C:) after call FltUnregisterFilter() I see PreCallback info
> (another words - PreCallback invoke) and after ~ 30 sec
> FltUnregisterFilter() exit.
> Driver verifier not detect errors…
> Why I see PreCallback till call FltUnregisterFilter()?
>
> —
> 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
>

Alex, thank you for reply! No, I don’t use WorkItems and don’t use operations pending…

You should! It’s fun! (just kidding)

So there’s a rundown ref in the unregister and it’s waiting for the
refcount on the Filter object to drop to 0… Maybe that’s it ? Do you do
something where you take a reference during CREATE or something like that ?

Thanks,
Alex.

On Tue, Oct 13, 2015 at 11:40 AM, wrote:

> Alex, thank you for reply! No, I don’t use WorkItems and don’t use
> operations pending…
>
> —
> 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
>

Ok, little bit new information : this situation happens only when I attach to \Device\Mup and use FltGetFileNameInformation(), but I call FltReleaseContext() and verifier not detect errors!

ECPs (FltAllocateExtraCreateParameter ) also hang but are not reported. Do
you use them?

Guys, no, I don’t use FltAllocateExtraCreateParameter(), only FltGetFileNameInformation()…After call FltUnregisterFilter() (filter attached to
\Device\Mup) I wait very log time (30-50sec) until the FltUnregisterFilter() return… I don’t have idea, may be this behavior normal?

So the 30 second thing sounds like a default timeout for creates for a
network FS or something. Do you use Normalized names ? If so, could you
please try switching to Opened and see if it helps ?

Thanks,
Alex.

On Wed, Oct 14, 2015 at 6:27 AM, wrote:

> Guys, no, I don’t use FltAllocateExtraCreateParameter(), only
> FltGetFileNameInformation()…After call FltUnregisterFilter() (filter
> attached to
> \Device\Mup) I wait very log time (30-50sec) until the
> FltUnregisterFilter() return… I don’t have idea, may be this behavior
> normal?
>
> —
> 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
>

Alex, I’m amazed at your knowledge and skills! Thank you! FLT_FILE_NAME_NORMALIZED to FLT_FILE_NAME_OPENED exchange helps!

Thanks! Just a lucky guess :).

What I thought might happen was that you call FltGetFileNameInformation()
in a preCreate (or postCreate) and something happens that causes one of the
opens involved to time out. Normally I’d say that if you’re doing IO in the
context of an operation and that operations gets cancelled then you should
cancel the IO you issued. However, I don’t see how you could do that with
FltGetFileNameInformation() so I suppose your options are:

  1. Use OPENED names (at least for network file systems)
  2. Implement your own name normalization (with the caveat that name
    normalization on a network filesystem isn’t easy and also might not
    actually work (depending what you’re trying to use it for - for example if
    you’re trying to figure out if you’re looking at the same file but shared
    in different ways, you might not be able to …)). If I were you I’d REALLY
    REALLY try to make OPENED names work :).

Thanks,
Alex

On Wed, Oct 14, 2015 at 9:43 AM, wrote:

> Alex, I’m amazed at your knowledge and skills! Thank you!
> FLT_FILE_NAME_NORMALIZED to FLT_FILE_NAME_OPENED exchange helps!
>
> —
> 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
>