MUP-Änderungen in Microsoft Windows Vista
Windows Vista implementiert eine Reihe von Änderungen am mehrfachen UNC-Anbieter (MUP), die sich auf Netzwerkumleitungen 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.sys auch den DFS-Client.
Unter Windows Vista ist ein neues Umleitungsmodell definiert:
MUP registriert sich als Dateisystem beim E/A-Manager, indem IoRegisterFileSystem aufgerufen wird.
Ein Netzwerkumleitungsanbieter registriert sich bei MUP mithilfe von FsRtlRegisterUncProviderEx , einer neuen Routine, die in Windows Vista eingeführt wurde.
Ein Netzwerkumleitungsobjekt übergibt ein unbenannte Geräteobjekt an FsRtlRegisterUncProviderEx.
Ein Netzwerkumleitungsanbieter übergibt einen Gerätenamen an FsRtlRegisterUncProviderEx.
Ein Netzwerkumleitungsor registriert sich nicht als Dateisystem beim E/A-Manager (ruft IoRegisterFileSystem nicht auf).
Alle Aufrufe von MUP an einen Netzwerkumleitungsor, einschließlich Präfixauflösung, IOCTLs und FSCTLs, erfolgen mit aktivierten APCs. Es wird erwartet, dass alle Aufrufe von anderen Komponenten an MUP mit aktivierten APCs erfolgen. Wenn Aufrufe mit FsRtlCancellableWaitForSingleObject oder FsRtlCancellableWaitForMultipleObjects verwendet werden, neuen Routinen, die in Windows Vista eingeführt wurden, wird dadurch sichergestellt, dass lange Wartezeiten abgebrochen werden können, wenn ein Thread, der eine E/A-Anforderung ausgestellt hat, beendet wird.
Die Präfixauflösung erfolgt mit IOCTL_REDIR_QUERY_PATH_EX, einer neuen IOCTL, die in Windows Vista eingeführt wurde.
Ein bei MUP registrierter Netzwerkumleitungsgerätename wird zu einer symbolischen Verknüpfung mit dem 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 Gerätenamen, der vom Netzwerkumleitungsanbieter im Aufruf von FsRtlRegisterUncProviderEx angegeben wird. Das Ziel dieser symbolischen Verknüpfung ist das MUP-Geräteobjekt (\Device\Mup).
Der Vorteil der Registrierung von MUP als Dateisystem und der Gerätename des Netzwerkumleitungs, der eine symbolische Verknüpfung mit dem MUP-Geräteobjekt darstellt, besteht darin, dass alle Remote-Dateisystem-E/A-Vorgänge und nicht nur namenbasierte Vorgänge MUP durchlaufen. Dateisystemfiltertreiber, die sich auf dem Remotedateisystemstapel befinden müssen, können also einfach an das MUP-Geräteobjekt anfügen. Es ist nicht mehr erforderlich, dass Dateisystemfiltertreiber Geräteobjektnamen des Anbieters (z. B. \Device\LanmanRedirector) in ihren Treiber hartcodieren. Auf diese Weise können Dateisystemfiltertreiber alle E/A-Vorgänge überwachen, die von einer einzelnen Anlage an alle Netzwerkumleitungen ausgegeben werden. Dadurch werden auch doppelte E/A-Vorgänge von Dateisystemfiltertreibern vor Windows Vista vermieden, die separat an DFS (mup.sys) und einzelne Netzwerkumleitungen (z. B. \Device\LanmanRedirector) angefügt wurden, um E/A-Vorgänge für beide zu überwachen.
Ein Dateisystemfiltertreiber, der an das MUP-Geräteobjekt angefügt ist, kann den Datenverkehr, der an bestimmte Netzwerkumleitungen gesendet wird, selektiv filtern. In dieser Situation ordnet der Filtertreiber die Gerätenamen der relevanten Netzwerkumleitungen anbieterbezeichnern zu, indem er die FsRtlMupGetProviderIdFromName-Routine aufruft. Der Filtertreiber kann dann bestimmen, ob er den Datenverkehr für ein bestimmtes Dateiobjekt filtern soll, indem er den Anbieterbezeichner vergleicht, der durch Aufrufen der FsRtlMupGetProviderInfoFromFileObject-Routine mit den Anbieterbezeichnern der relevanten Netzwerkdirektoren abgerufen wird.
Für eine Netzwerkumleitung, die dem Windows Vista-Umleitungsmodell entspricht:
Alle Dateiobjekte auf dem Remotedateisystemstapel werden in MUP aufgelöst. Daher gibt IoGetDeviceAttachmentBaseRef das Geräteobjekt für MUP zurück, nicht den Netzwerkumleitungsor, der das Dateiobjekt besitzt. Der Inhalt des Dateiobjekts befindet sich jedoch weiterhin im Besitz des Netzwerkumleitungs.
Eine IRP_MJ_CREATE, die für den Gerätenamen einer Netzwerkumleitung (z. B. \Device\LanmanRedirector\server\share) ausgestellt wurde, wird auf diesen Netzwerkumleitungsor ausgerichtet, ohne die MUP-Präfixauflösung zu durchlaufen, genau wie unter Windows Server 2003, Windows XP und Windows 2000.
Netzwerkumleitungen, die nicht auf windows Vista RDBSS basieren (dynamisch oder statisch verknüpfen), werden als "Legacy-Umleitungen" bezeichnet. Zu diesen Legacynetzwerkumleitungen gehören:
Für Windows Server 2003, Windows XP und Windows 2000 geschriebene Netzwerkumleitungen, die sich mithilfe von FsRtlRegisterUncProvider direkt bei MUP registrieren.
Für Windows Server 2003, Windows XP und Windows 2000 geschriebene Netzwerk-Miniumleitungen, die statisch mit der Rdbsslib.lib-Bibliothek für Windows Server 2003, Windows XP oder Windows 2000 verknüpft sind.
Für Windows Vista geschriebene Netzwerkumleitungen, die sich mithilfe von FsRtlRegisterUncProviderEx direkt bei MUP registrieren.
Netzwerk-Miniumleitungen, die dynamisch mit windows Vista RDBSS (rdbss.sys) verknüpft werden, entsprechen automatisch dem Windows Vista-Umleitungsmodell, da RDBSS mit FsRtlRegisterUncProviderEx bei MUP registriert wird. Netzwerk-Miniumleitungen, 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 für Windows Vista geschriebener Legacy-Netzwerkumleitung, der 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 und sich direkt mit dem FsRtlRegisterUncProvider bei MUP registrieren, funktionieren weiterhin genauso wie unter Windows Server 2003, Windows XP und Windows 2000. Für Windows Server 2003, Windows XP und Windows 2000 geschriebene Netzwerk-Miniumleitungen, 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 haben den Namen. Die Gerätenamen sind keine symbolischen Links und verweisen nicht auf \Device\MUP.
Dateiobjekte werden in das benannte Geräteobjekt des Netzwerkumleitungsobjekts aufgelöst.
MUP ist nur am Präfixauflösungsvorgang beteiligt. Nachdem der Netzwerkanbieter identifiziert wurde, "geht MUP aus dem Weg", indem STATUS_REPARSE zurückgegeben wird. Alle nachfolgenden Vorgänge durchlaufen MUP nicht.
Dieses Verhalten wurde beibehalten, um eine doppelte Filterung zu verhindern, die andernfalls auftreten würde, wenn der Anbietergerätename eine symbolische Verknüpfung mit \Device\MUP wäre. Diese doppelte Filterung tritt aus den folgenden Gründen auf:
Der Dateisystemfiltertreiber ist bereits an \Device\MUP angefügt.
Der Dateisystemfiltertreiber wird an ein beliebiges Registrierungssystem angefügt. Da Netzwerkumleitungen, die benannte Geräteobjekte verwenden, sich selbst als Dateisysteme registrieren, würde ein Dateisystemfiltertreiber die gleichen E/A-Vorgänge zweimal filtern.
Aufrufe an und von MUP unter Windows Vista erfolgen mit aktivierten APCs, was folgende Auswirkungen hat:
Es ist wichtig, codepfade, die von MUP aufgerufen werden, bei Bedarf mit geeigneten Mitteln, insbesondere IOCTL_REDIR_QUERY_PATH-Handlern, vor dem Anhalten von Threads zu schützen. Beachten Sie, dass es sich bei einem Thread-Anhalten um einen potenziell "ungebundenen Wartevorgang" handelt, der lange dauern kann.
Es ist wichtig sicherzustellen, dass jeder "Wait for E/O"-Vorgang mit Benutzermodusthreads (im Gegensatz zu Systemthreads) immer "abbruchbare Wartezeiten" verwendet. Ausführliche Informationen finden Sie in den Routinen FsRtlCancellableWaitForSingleObject und FsRtlCancellableWaitForMultipleObjects .
Deadlocks können auftreten, wenn ein Thread angehalten wird, der eine wichtige Sperre enthält. Es ist wichtig, Tests auszuführen, wenn Threads im Benutzermodus willkürlich angehalten werden, um nach Deadlockbedingungen zu suchen.
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, sodass die Anwendung beim Versuch, diesen Thread zu beenden, nicht in einem "nicht reagierenden" Zustand zu sein scheint.
Die Größe des Präfixcaches und das von MUP unter Windows Vista verwendete Timeout werden jetzt durch die folgenden Registrierungswerte gesteuert:
PrefixCacheSizeInKB
PrefixCacheTimeoutInSeconds.
Diese Registrierungswerte können ohne Neustart dynamisch 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 Bei MUP registrierte Netzwerkumleitungsanbieter fsRtlRegisterUncProvider oder FsRtlRegisterUncProviderEx aufruft. Legacynetzwerkumleitungen, die sich bei MUP registrieren, indem sie FsRtlRegisterUncProvider aufrufen, erhalten eine IOCTL_REDIR_QUERY_PATH Anforderung für die 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 bei MUP registrieren, indem Sie FsRtlRegisterUncProviderEx aufrufen, erhalten eine IOCTL_REDIR_QUERY_PATH_EX Anforderung für die Präfixauflösung. Beachten Sie, dass unter Windows Vista Netzwerk-Mini-Redirectors statisch mit rdbsslib.lib oder dynamisch mit rdbss.sys verknüpft fsRtlRegisterUncProviderEx indirekt über RDBSS aufrufen.
Die Eingabe- und Ausgabepuffer für IOCTL_REDIR_QUERY_PATH_EX sind wie folgt:
| Parameter verfügbar unter | Datenstrukturformat | |
Eingabepuffer |
IrpSp-> Parameters.DeviceIoControl.Type3InputBuffer |
QUERY_PATH_REQUEST_EX |
Ausgabepuffer |
IRP-UserBuffer> |
QUERY_PATH_RESPONSE |
Die IOCTL und die Datenstrukturen sind in ntifs.h definiert. Die Puffer werden aus einem nicht ausgelagerten Pool zugeordnet.
Netzwerkumleitungen sollten nur Kernelmodus-Absender dieser IOCTL berücksichtigen, indem sie überprüfen, 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;
| Strukturelement | Beschreibung |
|---|---|
pSecurityContext |
Ein Zeiger auf den Sicherheitskontext. |
EaLength |
Die Länge des Puffers für erweiterte Attribute in Bytes. |
pEaBuffer |
Zeiger auf den Puffer für erweiterte Attribute. |
PathName |
Eine nicht NULL beendete Unicode-Zeichenfolge des Formularserverfreigabepfads<><><>. |
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;
| Strukturelement | Beschreibung |
|---|---|
LengthAccepted |
Die Länge des Präfixes in Bytes, das vom Anbieter aus dem Unicode-Zeichenfolgenpfad beansprucht wird, der im PathName-Element der QUERY_PATH_REQUEST_EX-Struktur angegeben ist. |
Beachten Sie, dass IOCTL_REDIR_QUERY_PATH_EX eine METHOD_NEITHER IOCTL ist. Dies bedeutet, dass sich die Ein- 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 verwenden Sie den Eingabepufferzeiger, um die Antwort bereitzustellen.
Wenn ein UNC-Anbieter eine IOCTL_REDIR_QUERY_PATH_EX-Anforderung empfängt, muss er ermitteln, ob er den UNC-Pfad verarbeiten kann, der im PathName-Member der QUERY_PATH_REQUEST_EX-Struktur angegeben ist. Wenn ja, muss der UNC-Anbieter das LengthAccepted-Element der QUERY_PATH_RESPONSE-Struktur mit der Länge (in Bytes) des beanspruchten Präfixes aktualisieren und die IRP mit STATUS_SUCCESS abschließ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 darf das LengthAccepted-Element der QUERY_PATH_RESPONSE-Struktur nicht aktualisieren. Anbieter dürfen keines der anderen Member oder die PathName-Zeichenfolge unter keinen Bedingungen ä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 reguläre Erstellung einer Strukturverbindung handelt, ähnlich einem Createfile-Aufruf im Benutzermodus mit FILE_CREATE_TREE_CONNECTION Flag festgelegt. RDBSS sendet eine MRxCreateSrvCall-Anforderung an den Netzwerk-Mini-Redirector, gefolgt von einem Aufruf von MRxSrvCallWinnerNotify und MRxCreateVNetRoot. Dieser Präfixanspruch wird nicht als Aufruf von MRxLowIOSubmit[LOWIO_OP_IOCTL] empfangen. Wenn ein Netzwerkminiumleitungsor bei RDBSS registriert wird, wird die Treiberverteilungstabelle für die Netzwerkminiumleitung von RDBSS kopiert, um auf interne RDBSS-Einstiegspunkte zu verweisen. RDBSS empfängt dann diese IOCTL_REDIR_QUERY_PATH_EX intern für den Netzwerkminiumleitungsor und ruft MRxCreateSrvCall, MRxSrvCallWinnerNotify und MRxCreateVNetRoot auf. Die ursprüngliche IOCTL_REDIR_QUERY_PATH_EX IRP ist in der RX_CONTEXT enthalten, 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 der ursprüngliche IRP IRP_MJ_DEVICE_CONTROL war.
Der PrefixClaim.SuppliedPathName.Buffer-Member ist auf das PathName.Buffer-Element der QUERY_PATH_REQUEST_EX-Struktur festgelegt.
Das PrefixClaim.SuppliedPathName.Length-Element ist auf das PathName.Length-Element der QUERY_PATH_REQUEST_EX-Struktur festgelegt.
Das Create.ThisIsATreeConnectOpen-Element ist auf TRUE festgelegt.
Das Create.ThisIsAPrefixClaim-Element ist auf TRUE festgelegt.
Das Create.NtCreateParameters.SecurityContext-Element ist auf das SecurityContext-Element der QUERY_PATH_REQUEST_EX-Struktur festgelegt.
Das Create.EaBuffer-Element ist auf das pEaBuffer-Element der QUERY_PATH_REQUEST_EX-Struktur festgelegt.
Das Create.EaLength-Element ist auf das EaLength-Element der QUERY_PATH_REQUEST_EX-Struktur festgelegt.
Für das Create.Flags-Element ist das RX_CONTEXT_CREATE_FLAG_UNC_NAME Bit festgelegt.
Wenn der Netzwerkminiumleitung Details des Präfixanspruchs anzeigen möchte, kann er diese Member in der RX_CONTEXT Struktur lesen, die an MRxCreateSrvCall übergeben wird. Andernfalls kann nur versucht werden, eine Verbindung mit der Serverfreigabe herzustellen und STATUS_SUCCESS zurückzugeben, wenn der MRxCreateSrvCall-Aufruf erfolgreich war. RDBSS stellt den Präfixanspruch im Namen des Netzwerkminiumleitungs.