IOCTL_REDIR_QUERY_PATH ,how to unreference ?

Hello,

I ask the question in English and in French.
Sorry.

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.
OKAY.

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 :
Bonjour,

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.
OKAY.

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.

Merci.

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.

-scott
OSR
@OSRDrivers

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 osronline.com 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
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Mup\Parameters]
https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/mup-changes-in-microsoft-windows-vista

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
xxxxx@microfocus.com