MUP-Änderungen in Microsoft Windows Vista

Windows Vista führt eine Reihe von Änderungen an mehreren UNC-Anbietern (MUP) ein, die sich auf Netzwerk-Umleitungen auswirken können.

MUP und der DFS-Client (Distributed File System) befinden sich in separaten Binärdateien. Die MUP-Komponente befindet sich in mup.sys und der DFS-Client befindet sich in dfsc.sys. Unter Windows Server 2003, Windows XP und Windows 2000 enthielt die MUP-Kernelkomponente mup.sysauch den DFS-Client.

Ein neues Umleitungsmodell wird unter Windows Vista definiert:

• MUP registriert sich als Dateisystem beim E/A-Manager durch Aufrufen von IoRegisterFileSystem.

• Ein Netzwerkumleitungsmodul registriert sich mit MUP mit FsRtlRegisterUncProviderEx , einer neuen Routine, die in Windows Vista eingeführt wurde.

• Ein Netzwerkumleitungsmodul übergibt ein nicht benanntes Geräteobjekt an FsRtlRegisterUncProviderEx.

• Ein Netzwerkumleitungsmodul übergibt einen Gerätenamen an FsRtlRegisterUncProviderEx.

• Ein Netzwerkumleitungsmodul registriert sich nicht als Dateisystem beim E/A-Manager (ruft ioRegisterFileSystem nicht auf).

• Alle Aufrufe von MUP an einen Netzwerk-Umleiter, einschließlich der Präfixauflösung, IOCTLs und FSCTLs, werden mit aktivierten APCs getätigt. Es wird erwartet, dass alle Aufrufe von anderen Komponenten an MUP mit aktivierten APCs erfolgen. Wenn Aufrufe mit FsRtlCancellableWaitForSingleObject oder FsRtlCancellableWaitForMultipleObjects verwendet werden, stellen neue Routinen, die in Windows Vista eingeführt wurden, sicher, dass lange Wartezeiten abgebrochen werden können, wenn ein Thread, der eine E/A-Anforderung ausgestellt hat, beendet wird.

• Die Präfixauflösung wird mit IOCTL_REDIR_QUERY_PATH_EX durchgeführt, einer neuen IOCTL, die in Windows Vista eingeführt wurde.

• Ein bei MUP registrierter Netzwerkumleitungsgerätename wird zu einer symbolischen Verbindung zum MUP-Geräteobjekt.

Für einen Netzwerkumleitungsanbieter, der dem Windows Vista-Umleitungsmodell entspricht, erstellt MUP eine symbolische Verknüpfung im Objekt-Manager-Namespace mit dem vom Netzwerkumleitungsanbieter im Aufruf von FsRtlRegisterUncProviderEx angegebenen Gerätenamen. Das Ziel dieser symbolischen Verknüpfung ist das MUP-Geräteobjekt (\Device\Mup).

Der Vorteil der Registrierung von MUP als Dateisystem und dass der Gerätename des Netzwerkumleiters eine symbolische Verknüpfung zum MUP-Geräteobjekt ist, besteht darin, dass alle Remote-Dateisystem-E/A-Operationen, und nicht nur namensbasierte Operationen, über MUP abgewickelt werden. Daher können Dateisystemfiltertreiber, die sich im Remotedateisystemstapel befinden müssen, einfach an das MUP-Geräteobjekt anhängen. Es ist nicht erforderlich, dass Dateisystemfiltertreiber Provider-Geräteobjektnamen (z. B. \Device\LanmanRedirector) in ihren Treiber hardcodieren. Auf diese Weise können Dateisystemfiltertreiber alle E/A-Vorgänge überwachen, die von einer einzigen Anbindung an alle Netzwerk-Redirectoren ausgegeben werden. Dadurch werden auch doppelte E/A-Vorgänge entfernt, die von Dateisystemfiltertreibern vor Windows Vista erkannt werden, die separat an DFS (mup.sys) und einzelne Netzwerkumleitungen (z. B. Device\LanmanRedirector) angefügt wurden, um E/A-Vorgänge auf beide zu überwachen.

Ein Dateisystemfiltertreiber, der an das MUP-Geräteobjekt angefügt ist, kann selektiv den Datenverkehr filtern, der an bestimmte Netzwerkumleitungen gesendet wird. In diesem Fall ordnet der Filtertreiber die Gerätenamen der relevanten Netzwerkumleiter den Anbieterbezeichnern zu, indem er die Routine FsRtlMupGetProviderIdFromName aufruft. Der Filtertreiber kann dann bestimmen, ob der Datenverkehr für ein bestimmtes Dateiobjekt gefiltert werden soll, indem er den Anbieterbezeichner vergleicht, der durch Aufrufen der FsRtlMupGetProviderInfoFromFileObject-Routine mit den Anbieterbezeichnern der netzwerkdirektoren von Interesse abgerufen wird.

Für einen Netzwerkumleiter, der dem Windows Vista-Redirector-Modell entspricht:

• Alle Dateiobjekte im Remotedateisystemstapel werden in MUP aufgelöst. Daher gibt IoGetDeviceAttachmentBaseRef das Geräteobjekt für MUP zurück, nicht den Netzwerkumleiter, der das Dateiobjekt besitzt. Der Inhalt des Dateiobjekts befindet sich jedoch weiterhin im Besitz des Netzwerkumleitungsmoduls.

• Ein IRP_MJ_CREATE, das an den Gerätenamen eines Netzwerk-Redirectors (\Device\LanmanRedirector\server\share, z. B.) gesendet wird, wird auf diesen Netzwerk-Redirector ausgerichtet, ohne die MUP (Multiple UNC Provider)-Präfixauflösung zu durchlaufen, genau wie unter Windows Server 2003, Windows XP und Windows 2000.

Netzwerk-Redirectoren, die nicht auf Windows Vista RDBSS basieren (die dynamische oder statische Verknüpfungen verwenden), werden als "Legacy-Redirectoren" bezeichnet. Zu diesen älteren Netzwerkumleitungen gehören:

• Netzwerk-Redirectoren, die für Windows Server 2003, Windows XP und Windows 2000 geschrieben wurden und sich direkt bei MUP mit FsRtlRegisterUncProvider registrieren.

• Netzwerkminiumleitungen, die für Windows Server 2003, Windows XP und Windows 2000 geschrieben wurden, die statisch mit der rdbsslib.lib-Bibliothek für Windows Server 2003, Windows XP oder Windows 2000 verknüpft sind.

• Netzwerkumleitungen, die für Windows Vista geschrieben wurden und sich direkt mit MUP mithilfe von FsRtlRegisterUncProviderEx registrieren.

Netzwerkminiumleitungen, die dynamisch mit windows Vista RDBSS (rdbss.sys) verknüpfen, entsprechen automatisch dem Windows Vista-Umleitungsmodell, da RDBSS sich mit MUP mithilfe von FsRtlRegisterUncProviderEx registriert. Netzwerkminiumleitungen, die statisch mit windows Vista RDBSS (rdbsslib.lib) verknüpfen, entsprechen ebenfalls automatisch dem Windows Vista-Umleitungsmodell, da RDBSS mit FsRtlRegisterUncProviderEx bei MUP registriert wird.

Ein legacy-Netzwerkumleitungsmodul, der für Windows Vista geschrieben wurde, das sich direkt bei MUP registriert, muss dem Windows Vista-Umleitungsmodell entsprechen.

Netzwerkumleitungen, die für Windows Server 2003, Windows XP und Windows 2000 geschrieben wurden, die sich mit MUP direkt mit dem FsRtlRegisterUncProvider registrieren, funktionieren weiterhin genauso wie unter Windows Server 2003, Windows XP und Windows 2000. Netzwerkminiumleitungen, die für Windows Server 2003, Windows XP und Windows 2000 geschrieben wurden, die statisch mit der rdbsslib.lib-Bibliothek für Windows Server 2003, Windows XP und Windows 2000 verknüpft sind, funktionieren weiterhin genauso wie unter Windows Server 2003, Windows XP und Windows 2000. Diese älteren Netzwerkumleitungen und Miniumleitungen weisen das folgende Verhalten auf:

• Sie sind für Dateisystemfiltertreiber sichtbar, die die Dateisystemregistrierung überwachen.

• Ihre Geräteobjekte werden benannt. Die Gerätenamen sind keine symbolischen Verknüpfungen und verweisen nicht auf \Device\MUP.

• Dateiobjekte werden auf das benannte Geräteobjekt des Netzwerkumleiters aufgelöst.

• MUP ist nur an der Präfixauflösung beteiligt. Sobald der Netzwerkanbieter identifiziert wurde, wird MUP "vom Weg" entfernt, indem STATUS_REPARSE zurückgegeben wird. Alle nachfolgenden Vorgänge werden nicht über MUP geleitet.

Dieses Verhalten wurde beibehalten, um doppelte Filterung zu verhindern, die andernfalls auftreten würden, wenn der Gerätename des Anbieters eine symbolische Verknüpfung zu \Device\MUP wäre. Diese doppelte Filterung würde aus folgenden Gründen auftreten:

• Der Dateisystemfiltertreiber ist bereits an \Device\MUP angefügt.

• Der Dateisystemfiltertreiber hängt sich an jedes registrierende Dateisystem an. Da Netzwerkumleitungen, die benannte Geräteobjekte verwenden, sich selbst als Dateisysteme registrieren, würde ein Dateisystemfiltertreiber die gleiche E/A zweimal filtern.

Aufrufe von und von MUP unter Windows Vista werden mit aktivierten APCs getätigt, die folgende Auswirkungen haben:

• Es ist wichtig, Codepfade bei Bedarf mit geeigneten Mitteln vor der Threadaussetzung zu schützen, insbesondere die IOCTL_REDIR_QUERY_PATH-Handler, die von MUP aufgerufen werden. Beachten Sie, dass es sich bei einem Thread suspend um einen potenziell "ungebundenen Wartevorgang" handelt, der lange dauern kann.

• Es ist wichtig sicherzustellen, dass alle "Wait for I/O"-Vorgänge mit Benutzermodusthreads (im Gegensatz zu Systemthreads) immer "abbruchbare Wartezeiten" verwenden. Details finden Sie in den FsRtlCancellableWaitForSingleObject - und FsRtlCancellableWaitForMultipleObjects-Routinen .

• Deadlocks können auftreten, wenn ein Thread angehalten wird, der eine wichtige Sperre enthält. Es ist wichtig, Tests auszuführen, wenn es Threads im Benutzermodus gibt, die willkürlich angehalten werden, um auf Deadlock-Bedingungen zu überprüfen.

• Es ist wichtig, Tests auszuführen, um zu überprüfen, ob "Warten auf E/A-Vorgänge" wirklich abgebrochen werden kann und dass eine Benutzermodusanwendung einen Thread schnell genug beenden kann, damit die Anwendung nicht in einem "nicht reagierenden" Zustand angezeigt wird, wenn Sie versuchen, den betreffenden Thread zu beenden.

Die Von MUP unter Windows Vista verwendete Präfixcachegröße und -timeout werden jetzt durch die folgenden Registrierungswerte gesteuert:

• PrefixCacheGrößeInKB

• PrefixCacheTimeoutInSeconds.

Diese Registrierungswerte können dynamisch ohne Neustart geändert werden. Diese Registrierungswerte befinden sich unter dem folgenden Registrierungsschlüssel:

HKLM\System\CurrentControlSet\Services\Mup\Parameters.

Der ProviderOrder-Registrierungswert, der die Reihenfolge bestimmt, in der MUP Präfixauflösungsanforderungen an einzelne Umleitungen ausgibt, kann dynamisch geändert werden, ohne das System neu zu starten. Dieser Registrierungswert befindet sich unter dem folgenden Registrierungsschlüssel:

HKLM\CurrentControlSet\Control\NetworkProvider\Order

Unter Windows Vista führt MUP die Präfixauflösung unterschiedlich aus, je nachdem, ob der Netzwerk-Redirector bei MUP durch Aufrufen von FsRtlRegisterUncProvider oder FsRtlRegisterUncProviderEx registriert wurde. Legacy-Netzwerkumleiter, die sich bei MUP registrieren, indem FsRtlRegisterUncProvider aufgerufen wird, erhalten einen IOCTL_REDIR_QUERY_PATH-Anforderung zur Präfixauflösung. Dies ist die gleiche Methode, die unter Windows Server 2003, Windows XP und Windows 2000 verwendet wird.

Netzwerkumleitungen, die dem Windows Vista-Umleitungsmodell entsprechen und sich mit MUP registrieren, indem FsRtlRegisterUncProviderEx aufgerufen wird, erhalten eine IOCTL_REDIR_QUERY_PATH_EX Anforderung zur Präfixauflösung. Beachten Sie, dass unter Windows Vista Netzwerk-Mini-Redirectoren, die statisch mit rdbsslib.lib verknüpft oder dynamisch mit rdbss.sys verbunden sind, FsRtlRegisterUncProviderEx indirekt über RDBSS aufrufen werden.

Die Eingabe- und Ausgabepuffer für IOCTL_REDIR_QUERY_PATH_EX sind wie folgt:

Die IOCTL und die Datenstrukturen werden in ntifs.h definiert. Die Puffer werden aus dem nicht-ausgelagerten Pool zugeordnet.

Netzwerkumleitungen sollten nur Kernelmodus-Absender dieses IOCTL berücksichtigen, indem überprüft wird, ob Irp->RequestorMode-KernelMode-ist.

MUP verwendet die QUERY_PATH_REQUEST_EX Datenstruktur für die Anforderungsinformationen.

typedef struct _QUERY_PATH_REQUEST_EX {
  PIO_SECURITY_CONTEXT  pSecurityContext;
 ULONG  EaLength;
 PVOID  pEaBuffer;
  UNICODE_STRING  PathName;
} QUERY_PATH_REQUEST_EX, *PQUERY_PATH_REQUEST_EX;

UNC-Anbieter sollten die QUERY_PATH_RESPONSE Datenstruktur für die Antwortinformationen verwenden.

typedef struct _QUERY_PATH_RESPONSE {
 ULONG  LengthAccepted;
} QUERY_PATH_RESPONSE, *PQUERY_PATH_RESPONSE;

Beachten Sie, dass IOCTL_REDIR_QUERY_PATH_EX ein METHOD_NEITHER IOCTL ist. Dies bedeutet, dass sich die Eingabe- und Ausgabepuffer möglicherweise nicht an derselben Adresse befinden. Ein häufiger Fehler von UNC-Anbietern besteht darin, davon auszugehen, dass der Eingabepuffer und der Ausgabepuffer identisch sind und den Eingabepufferzeiger verwenden, um die Antwort bereitzustellen.

Wenn ein UNC-Anbieter eine IOCTL_REDIR_QUERY_PATH_EX Anforderung empfängt, muss er bestimmen, ob er den UNC-Pfad verarbeiten kann, der im PathName-Element der QUERY_PATH_REQUEST_EX-Struktur angegeben ist. Wenn ja, hat der UNC-Anbieter das LengthAccepted-Mitglied der QUERY_PATH_RESPONSE-Struktur mit der Länge (in Bytes) des Präfixes zu aktualisieren, das er beansprucht hat, und den IRP mit STATUS_SUCCESS abzuschließen. Wenn der Anbieter den angegebenen UNC-Pfad nicht verarbeiten kann, muss die IOCTL_REDIR_QUERY_PATH_EX Anforderung mit einem entsprechenden NTSTATUS-Fehlercode fehlschlagen und das LengthAccepted-Element der QUERY_PATH_RESPONSE-Struktur nicht aktualisieren. Anbieter dürfen keines der anderen Member oder die PathName-Zeichenfolge unter irgendeiner Bedingung ändern.

Unter Windows Vista erhält ein Netzwerk-Mini-Redirector, der auf der Verwendung von RDBSS basiert und die Unterstützung als UNC-Anbieter angibt, diesen Präfixanspruch, als ob es sich um eine normale Baumverbindungsherstellung handelt, ähnlich wie ein Aufruf von Createfile im Benutzermodus mit gesetztem FILE_CREATE_TREE_CONNECTION-Flag. RDBSS wird eine MRxCreateSrvCall-Anforderung an den Netzwerk-Mini-Redirector senden, gefolgt von einem Aufruf von MRxSrvCallWinnerNotify und MRxCreateVNetRoot. Dieser Präfixanspruch wird nicht als Aufruf von MRxLowIOSubmit[LOWIO_OP_IOCTL]empfangen. Wenn ein Netzwerk-Mini-Redirector mit RDBSS registriert wird, wird die Treiber-Dispatch-Tabelle für den Netzwerk-Mini-Redirector von RDBSS kopiert, um auf interne RDBSS-Einträge zu verweisen. RDBSS empfängt daraufhin diesen IOCTL_REDIR_QUERY_PATH_EX intern für den Netzwerk-Mini-Redirector und ruft MRxCreateSrvCall, MRxSrvCallWinnerNotify und MRxCreateVNetRoot auf. Das ursprüngliche IOCTL_REDIR_QUERY_PATH_EX IRP wird in der RX_CONTEXT enthalten sein, die an die MRxCreateSrvCall-Routine übergeben wird. Darüber hinaus werden die folgenden Member in der RX_CONTEXT, die an MRxCreateSrvCall übergeben werden, geändert:

Das MajorFunction-Element ist auf IRP_MJ_CREATE festgelegt, obwohl das ursprüngliche IRP IRP_MJ_DEVICE_CONTROL wurde.

Der PrefixClaim.SuppliedPathName.Buffer-Member wird auf das PathName.Buffer-Element der QUERY_PATH_REQUEST_EX-Struktur festgelegt.

Das PrefixClaim.SuppliedPathName.Length-Element wird auf das PathName.Length-Element der QUERY_PATH_REQUEST_EX-Struktur festgelegt.

Das Create.ThisIsATreeConnectOpen-Element ist auf TRUE festgelegt.

Der Create.ThisIsAPrefixClaim-Member ist auf TRUE festgelegt.

Der Create.NtCreateParameters.SecurityContext-Member ist auf das SecurityContext-Element der QUERY_PATH_REQUEST_EX-Struktur festgelegt.

Der Create.EaBuffer-Member ist auf das pEaBuffer-Element der QUERY_PATH_REQUEST_EX-Struktur festgelegt.

Das Create.EaLength-Mitglied wird auf das EaLength-Element der QUERY_PATH_REQUEST_EX-Struktur festgelegt.

Der Create.Flags-Member wird das RX_CONTEXT_CREATE_FLAG_UNC_NAME Bit gesetzt haben.

Wenn der Netzwerk-Mini-Redirector Details des Präfixanspruchs sehen möchte, kann er diese Mitglieder in der RX_CONTEXT-Struktur lesen, die an MRxCreateSrvCall übergeben wird. Andernfalls kann es einfach versuchen, eine Verbindung mit der Serverfreigabe herzustellen und STATUS_SUCCESS zurückzugeben, wenn der Aufruf von MRxCreateSrvCall erfolgreich war. RDBSS wird im Auftrag des Netzwerk-Mini-Redirectors den Präfix-Anspruch erheben.