Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results


More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

IOCTL_REDIR_QUERY_PATH ,how to unreference ?

Gova_GimerGova_Gimer Member - All Emails Posts: 43

I ask the question in English and in French.

In english :

In the MUP, at each IOCTL function IOCTL_REDIR_QUERY_PATH, Windows
reference the UNC link (eg. \\test\l1) by data receive 'QUERY_PATH_RESPONSE' if
it returns STATUS_SUCCESS.

But how to do the opposite?
Do That is how deference or purge the UNC ?
Do That is, the OS recalls the IOCTL function IOCTL_REDIR_QUERY_PATH ?
because he is called only once

I developed a kernel MUP UNC service to mount virtual disk filesystem on a UNC Network.
AND also I develop a MUP UNC kernel service to mount rawsystem virtual disk on a UNC Network.

When I mount my filesystem disk (Driver 'A') on a UNC (eg \\test\l1) it works good!!!
I unmount my filesystem disk and mount a rawsystem disk (Driver 'B') on the same UNC (\\test\l1).
It does not work, and I took a long time to find the problem but not resolved:
when I open the UNC '\\ test \ l1' Windows does not send the famous ioctl function IOCTL_REDIR_QUERY_PATH, consequence
it is the DeviceObject MUP (Driver 'A') of my driver filesystem which is always called (AND NOT THAT OF THE DRIVER RAWSYSTEM (Driver 'B')).
It is that of the driver 'A' which is always called instead Driver 'B', consequence the function IRP_MJ_CREATE of the driver FileSystem
which is called returns STATUS_ACCESS_DENIED because the UNC (\\test\l1) of the driver 'A' is no longer referenced because I had to unmount the filesystem disk.
the UNC address \\test\l1 is referenced to the driver 'B'.

How to purge the MUP?

For information :
My disk driver DiskSystem (Driver 'A') has its own MUP device.
My disk driver RawSystem (Driver 'B') has its own MUP device.
Also there are 2 providers MUP (One for Driver 'A' and one for Driver 'B')

Driver 'A' -> driver disk filesystem
Driver 'B' -> driver disk rawsystem.

Thank you.

In French version :

Dans les MUP ,? chaque fonction IOCTL IOCTL_REDIR_QUERY_PATH, Windows
r?f?rence le lien UNC (eg. \\test\l1) par data receive 'QUERY_PATH_RESPONSE' si
il renvoie STATUS_SUCCESS.

Mais comment faire l'inverse ?
C'est ? dire le deferencer ou purger les UNC. C'est ? dire que the OS rappelle la fonction IOCTL IOCTL_REDIR_QUERY_PATH,
car il est appell? qu'une seule fois.

J'ai d?velopper un service kernel MUP UNC pour monter des disque virtuelle filesystem sur un UNC Network.
ET aussi j'ai developper un service kernel MUP UNC pour monter des disque virtuelle rawsystem sur un UNC Network.

Quand je monte mon disque filesystem (Driver 'A') sur un UNC (ex. \\test\l1) ca marche !!!
Je d?monte mon disque filesystem et je monte un disque rawsystem (Driver 'B') sur le m?me UNC (\\test\l1).
Ca ne marche pas , et j'ai mis longtemps ? trouver le probl?me mais pas r?solut :
quand j'ouvre l'UNC '\\test\l1' Windows ne n'envoie pas le fameux fonction ioctl IOCTL_REDIR_QUERY_PATH ,cons?quence
c'est le DeviceObject MUP (Driver 'A') de mon driver filesystem qui est toujours appell? (ET NON PAS CELLE DU DRIVER RAWSYSTEM (Driver 'B')).
C'est celui du driver 'A' qui est appell? , cons?quence la fonction IRP_MJ_CREATE du driver FileSystem
qui est appell? retourne STATUS_ACCESS_DENIED car l'UNC (\\test\l1) du driver 'A' n'est plus r?f?rencer car j'avais d?monter le disque filesystem.
l'adresse UNC \\test\l1 est r?f?rencer au driver 'B'.

Comment purger le MUP ?

Pour information :
Le driver disk FileSystem (Driver 'A') comporte son propre device MUP.
Le driver disk RawSystem (Driver 'B') comporte son propre device MUP.
Aussi il y a 2 providers MUP (Pour Driver 'A' et pour Driver 'B')

Driver 'A' -> driver disk filesystem
Driver 'B' -> driver disk rawsystem.



  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,450
    Did you try deregistering with FsRtlDeregisterUncProvider and then
    re-registering the UNC provider? I don't think there's any other way to tell
    MUP that you no longer know how to talk to a particular server/share.



  • Alan_AdamsAlan_Adams Member - All Emails Posts: 15
    I agree with Scott's response. The reply below had been posted August
    6, but it doesn't appear to be in the actual live message store.
    Probably just lost in my recent shuffle of IDs in
    preparation for the upcoming forum software change:

    > Do That is how deference or purge the UNC ?
    > Do That is, the OS recalls the IOCTL function IOCTL_REDIR_QUERY_PATH ?
    > because he is called only once

    I don't think Microsoft's MUP provided for any "deregister this one
    specific path." You can "stop being a UNC provider entirely" by
    calling FsRtlDeregisterUncProvider, and this ostensibly would be MUP's
    opportunity to immediately invalidate ALL the paths from your driver
    which were still in MUP's prefix cache.

    But to my understanding, Microsoft's MUP isn't designed for "per-path
    fast ownership changes" like what you're describing. Meaning there
    isn't an "invalidate this one specific path from the MUP cache" action
    that you can initiate with MUP.

    It is however completely valid and expected that a UNC path such as
    "\\test\11" can "change ownership." e.g. The path might be owned by
    "driver A" when MUP first queries, but when MUP queries again in the
    future, it will be "driver B" which affirmatively handles that path.

    But MUP is who is in control of the decision regarding "when am I
    going to choose to issue the IOCTL_REDIR_QUERY_PATH/_EX for this path
    again"; versus MUP deciding to continue using the existing prefix
    cache entry it already has for that path.

    Windows has changed and tweaked the MUP cache timeout over the years.
    It used to be hard-coded, but the "MUP Changes in Microsoft Windows
    Vista" document confirmed that it should be configurable using a
    "PrefixCacheTimeoutInSeconds" policy set under

    You could potentially change the configuration just for your testing
    environment, to speed up testing. But you probably DON'T want to
    change the default on customer machines just to try and achieve a
    "per-path fast ownership change" for your driver.

    MUP's cache is definitively beneficial to performance, since each new
    query MUP chooses to issue can end up resulting in new name resolution
    and other slow activities across the network, depending on the
    redirectors installed on a given customer machine.

    Alan Adams
    Client for Open Enterprise Server
    Micro Focus
    [email protected]
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging 15 November 2021 Live, Online