Initialisieren eines Protokolltreibers
Das System ruft die DriverEntry-Routine eines Protokolltreibers auf, nachdem der Treiber geladen wurde. Protokolltreiber werden als Systemdienste geladen. Sie können jederzeit vor, während oder nach dem Laden der Miniporttreiber geladen werden.
Protokolltreiber weisen Treiberressourcen zu und registrieren ProtocolXxx-Funktionen in DriverEntry. Dazu gehören CoNDIS-Clients und eigenständige Anrufmanager. Um seine ProtocolXxx-Funktionen bei NDIS zu registrieren, ruft ein Protokolltreiber die Funktion NdisRegisterProtocolDriver auf.
DriverEntry gibt STATUS_SUCCESS oder die entsprechende NDIS_STATUS_SUCCESS zurück, wenn der Treiber erfolgreich als NDIS-Protokolltreiber registriert wurde. Wenn die Initialisierung von DriverEntry fehlschlägt, indem ein Fehler status weitergegeben wird, der von einer NdisXxx-Funktion oder einer Kernelmodusunterstützungsroutine zurückgegeben wurde, bleibt der Treiber nicht geladen. DriverEntry muss synchron ausgeführt werden. Das heißt, es kann keine STATUS_PENDING oder seine äquivalenten NDIS_STATUS_PENDING zurückgeben.
Die DriverEntry-Funktion eines NDIS-Protokolltreibers muss die NdisRegisterProtocolDriver-Funktion aufrufen. Um die ProtocolXxx-Einstiegspunkte des Treibers bei der NDIS-Bibliothek zu registrieren, initialisiert ein Protokolltreiber eine NDIS_PROTOCOL_DRIVER_CHARACTERISTICS-Struktur und übergibt sie an NdisRegisterProtocolDriver.
Treiber, die NdisRegisterProtocolDriver aufrufen, müssen auf einen sofortigen Aufruf einer ihrer ProtocolXxx-Funktionen vorbereitet sein.
NDIS-Protokolltreiber stellen die folgenden ProtocolXxx-Funktionen bereit, bei denen es sich um aktualisierte Versionen der Funktionen handelt, die Legacytreiber bereitstellen:
ProtocolCloseAdapterCompleteEx
NDIS-Protokolltreiber stellen die folgenden ProtocolXxx-Funktionen für Sende- und Empfangsvorgänge bereit:
ProtocolSendNetBufferListsComplete
Alle Typen von NDIS-Protokolltreibern sollten voll funktionsfähige Funktionen ProtocolBindAdapterEx und ProtocolUnbindAdapterEx registrieren, um Plug & Play (PnP) zu unterstützen. Im Allgemeinen sollte eine DriverEntry-FunktionNdisRegisterProtocolDriver unmittelbar vor der Rückgabe des Steuerelements mit dem status Wert STATUS_SUCCESS oder NDIS_STATUS_SUCCESS aufrufen.
Jeder Protokolltreiber, der zusätzlich zu seinen von NDIS definierten ProtocolXxx-Funktionen eine Reihe von Standard-Kernelmodustreiberroutinen exportiert, muss die Einstiegspunkte für diese Treiberroutinen im angegebenen Treiberobjekt festlegen, das an seine DriverEntry-Funktion übergeben wird. Weitere Informationen zur Funktionalität der DriverEntry-Funktion eines solchen Protokolltreibers finden Sie unter Schreiben einer DriverEntry-Routine.
Wenn beim Versuch, Ressourcen zuzuweisen, die der Treiber für die Ausführung von Netzwerk-E/A-Vorgängen benötigt, fehlschlägt, sollte DriverEntry alle ressourcen freigeben, die bereits zugewiesen wurden, bevor die Steuerung mit einem anderen status als STATUS_SUCCESS oder NDIS_STATUS_SUCCESS zurückgegeben wird.
Wenn nach einem erfolgreichen Aufruf von NdisRegisterProtocolDriver ein Fehler auftritt, muss der Treiber die NdisDeregisterProtocolDriver-Funktion aufrufen, bevor DriverEntry zurückgibt.
Damit ein Protokolltreiber optionale Dienste konfigurieren kann, ruft NDIS die ProtocolSetOptions-Funktion im Kontext des Aufrufs des Protokolltreibers an NdisRegisterProtocolDriver auf. Weitere Informationen zu optionalen Diensten finden Sie unter Konfigurieren von optionalen Protokolltreiberdiensten.
CoNDIS-Clienttreiber müssen die NdisSetOptionalHandlers-Funktion aus der ProtocolSetOptions-Funktion aufrufen. Der Treiber initialisiert eine NDIS_CO_CLIENT_OPTIONAL_HANDLERS-Struktur und übergibt sie am OptionalHandlers-Parameter von NdisSetOptionalHandlers.
Eigenständige CoNDIS-Aufruf-Manager müssen auch die Funktion NdisSetOptionalHandlers aus der ProtocolSetOptions-Funktion aufrufen. Der Treiber initialisiert eine NDIS_CO_CALL_MANAGER_OPTIONAL_HANDLERS-Struktur und übergibt sie am OptionalHandlers-Parameter von NdisSetOptionalHandlers.
MCMs sind keine Protokolltreiber. Daher muss die Funktion NdisSetOptionalHandlers aus der MiniportSetOptions-Funktion aufgerufen werden. Der MCM initialisiert eine NDIS_CO_CALL_MANAGER_OPTIONAL_HANDLERS-Struktur und übergibt sie am OptionalHandlers-Parameter von NdisSetOptionalHandlers.
Um die Registrierung bei NDIS aufzuheben, ruft ein Protokolltreiber NdisDeregisterProtocolDriver aus seiner Unload-Routine auf.
Um Bereinigungsvorgänge auszuführen, bevor ein Protokolltreiber deinstalliert wird, kann ein Protokolltreiber eine ProtocolUninstall-Funktion registrieren. Die ProtocolUninstall-Funktion ist optional. Beispielsweise erfordert der untere Protokollrand eines Zwischentreibers möglicherweise eine ProtocolUninstall-Funktion . Der Zwischentreiber kann seine Protokoll-Edgeressourcen in ProtocolUninstall freigeben, bevor NDIS seine MiniportDriverUnload-Funktion aufruft.