E/A-Überprüfung
Die Treiberüberprüfung verfügt über zwei Ebenen der E/A-Überprüfung:
Die E/A-Überprüfung der Stufe 1 ist immer aktiv, wenn E/A-Überprüfung ausgewählt ist.
Die E/A-Überprüfung der Stufe 2 ist immer aktiv, wenn in Windows XP und höher E/A-Überprüfung ausgewählt ist.
Siehe auch:Erweiterte E/A-Überprüfung In Windows 7 und höheren Versionen des Windows-Betriebssystems wird die erweiterte E/A-Überprüfung automatisch aktiviert, wenn Sie E/A-Überprüfung auswählen. Es ist nicht verfügbar oder es ist nicht erforderlich, sie als separate Option auszuwählen.
E/A-Überprüfung der Stufe 1
Wenn die E/A-Überprüfung der Stufe 1 aktiviert ist, werden alle IRPs, die über IoAllocateIrp abgerufen werden, aus einem speziellen Pool zugeordnet und ihre Verwendung nachverfolgt.
Darüber hinaus überprüft die Treiberüberprüfung auf ungültige E/A-Aufrufe, einschließlich:
Versucht, eine IRP freizugeben, deren Typ nicht IO_TYPE_IRP
Durchläufe ungültiger Geräteobjekte an IoCallDriver
Durchläufe einer IRP an IoCompleteRequest, die ungültige status enthält oder noch einen Abbruchroutinesatz aufweist
Änderungen an der IRQL über einen Aufruf der Treiberverteilungsroutine
Versucht, eine IRP frei zu geben, die einem Thread zugeordnet bleibt
Übergeben eines Geräteobjekts an IoInitializeTimer , das bereits einen initialisierten Timer enthält
Durchläufe eines ungültigen Puffers an IoBuildAsynchronousFsdRequest oder IoBuildDeviceIoControlRequest
Durchläufe eines E/A-status-Blocks an einen IRP, wenn dieser E/A-status-Block einem Stapel zugeordnet wird, der sich zu weit entfernt hat
Übergeben eines Ereignisobjekts an eine IRP, wenn dieses Ereignisobjekt auf einem Stapel zugeordnet wird, der sich zu weit entfernt hat
Da der spezielle IRP-Pool eine begrenzte Größe aufweist, ist die E/A-Überprüfung am effektivsten, wenn sie jeweils nur auf einem Treiber verwendet wird.
Fehler der E/A-Überprüfungsstufe 1 führen dazu, dass Fehlerüberprüfungen 0xC9 ausgestellt werden. Der erste Parameter dieser Fehlerüberprüfung gibt an, welche Verletzung aufgetreten ist. Eine vollständige Parameterauflistung finden Sie unter Fehlerprüfung 0xC9 (DRIVER_VERIFIER_IOMANAGER_VIOLATION).
E/A-Überprüfung der Stufe 2
E/A-Überprüfungsstufe 2-Fehler werden auf unterschiedliche Weise angezeigt: auf dem blauen Bildschirm, in einer Absturzabbilddatei und in einem Kerneldebugger.
Auf dem blauen Bildschirm werden diese Fehler durch die Meldung IO SYSTEM VERIFICATION ERROR und die Zeichenfolge WDM DRIVER ERRORXXX notiert, wobei XXX ein E/A-Fehlercode ist.
In einer Absturzabbilddatei werden die meisten dieser Fehler durch die Meldung BugCheck 0xC9 (DRIVER_VERIFIER_IOMANAGER_VIOLATION) zusammen mit dem E/A-Fehlercode notiert. In diesem Fall wird der E/A-Fehlercode als erster Parameter der Fehlerüberprüfung 0xC9 angezeigt. Der Rest wird durch die Meldung Bug Check 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION) zusammen mit einem Treiberüberprüfungsfehlercode notiert. In diesem Fall wird der Fehlercode der Treiberüberprüfung als erster Parameter der Fehlerüberprüfung 0xC4 angezeigt.
In einem Kerneldebugger (KD oder WinDbg) werden diese Fehler durch die Meldung WDM DRIVER ERROR und eine beschreibende Textzeichenfolge notiert. Wenn der Kerneldebugger aktiv ist, ist es möglich, die Fehler der Ebene 2 zu ignorieren und den Systembetrieb fortzusetzen. (Dies ist bei anderen Fehlerüberprüfungen nicht möglich.)
Der Bluescreen, die Absturzabbilddatei und der Kerneldebugger zeigen jeweils zusätzliche Informationen an. Eine vollständige Beschreibung der meisten E/A-Überprüfungsstufe 2-Fehlermeldungen finden Sie unter Fehlerüberprüfung 0xC9. Weitere Informationen finden Sie unter Fehlerüberprüfung 0xC4.
Ab Windows Vista sucht die E/A-Überprüfungsoption auf die folgenden Treiberfehler:
Das Abschließen und Abbrechen von IRPs, die aus Anwendungen im Benutzermodus stammen, dauert zu lange.
Freigabe einer noch nicht erworbenen Remove-Sperre.
Aufrufen von IoReleaseRemoveLock oder IoReleaseRemoveLockAndWait mit einem Tagparameter, der sich vom Tagparameter unterscheidet, der im entsprechenden IoAcquireRemoveLock-Aufruf verwendet wird.
Aufrufen von IoCallDriver mit deaktivierten Interrupts.
Aufrufen von IoCallDriver bei IRQL größer als DISPATCH_LEVEL.
Rückkehr von einer Treiber-Dispatchroutine mit deaktivierten Interrupts.
Rückkehr von einer Treiberverteilungsroutine mit einem geänderten IRQL.
Rückkehr von einer Treiberverteilungsroutine mit deaktivierten APCs. In diesem Fall hat der Treiber möglicherweise mehr KeEnterCriticalRegion aufgerufen als KeLeaveCriticalRegion, was die Hauptursache für die Fehlerüberprüfung 0x20 (KERNEL_APC_PENDING_DURING_EXIT) und die Fehlerüberprüfung 0x1 (APC_INDEX_MISMATCH) ist.
Ab Windows 7 überprüft die Option E/A-Überprüfung die folgenden Treiberfehler:
- Versucht, IRPs durch Aufrufen von ExFreePool freizugeben. IRPs müssen mit IoFreeIrp freigegeben werden.
Darüber hinaus können Sie diese Option verwenden, um einen weiteren häufigen Treiberfehler zu erkennen– das erneute Initialisieren von Entfernungssperren. Sperren entfernen Datenstrukturen sollten innerhalb von Geräteerweiterungen zugeordnet werden. Dadurch wird sichergestellt, dass der E/A-Manager den Arbeitsspeicher, der die IO_REMOVE_LOCK-Struktur enthält, nur freigibt, wenn das Geräteobjekt gelöscht wird. Wenn der Treiber die folgenden drei Schritte ausführt, ist es möglich, dass nach Schritt 2 eine Anwendung oder ein Treiber weiterhin einen Verweis auf Device1 enthält:
- Weist die IO_REMOVE_LOCK-Struktur zu, die Device1 entspricht, übernimmt jedoch die Zuordnung außerhalb der Device1-Erweiterung.
- Ruft IoReleaseRemoveLockAndWait auf , wenn Device1 entfernt wird.
- Ruft IoInitializeRemoveLock für dieselbe Sperre auf, um sie als Entfernungssperre für Device2 wiederzuverwenden.
Es ist möglich, dass nach Schritt 2 eine Anwendung oder ein Treiber weiterhin einen Verweis auf Device1 enthält. Die Anwendung oder der Treiber kann weiterhin Anforderungen an Device1 senden, auch wenn dieses Gerät entfernt wurde. Daher ist es nicht sicher, denselben Speicher wie eine neue Sperre wiederzuverwenden, bis der E/A-Manager Device1 löscht. Das erneute Initialisieren derselben Sperre, während ein anderer Thread versucht, sie abzurufen, kann zur Beschädigung der Sperre führen, mit unvorhersehbaren Ergebnissen für den Treiber und das gesamte System.
In Windows 7 und höheren Versionen des Windows-Betriebssystems wird die erweiterte E/A-Überprüfung automatisch aktiviert, wenn Sie E/A-Überprüfung auswählen.
Aktivieren dieser Option
Sie können die E/A-Überprüfungsfunktion für einen oder mehrere Treiber aktivieren, indem Sie den Treiberüberprüfungs-Manager oder die Verifier.exe Befehlszeile verwenden. Ausführliche Informationen finden Sie unter Auswählen von Treiberüberprüfungsoptionen.
An der Befehlszeile.
In der Befehlszeile wird die E/A-Überprüfungsoption durch Bit 4 (0x10) dargestellt. Verwenden Sie zum Aktivieren der E/A-Überprüfung den Flagwert 0x10, oder fügen Sie dem Flagwert 0x10 hinzu. Beispiel:
verifier /flags 0x10 /driver MyDriver.sys
Das Feature ist nach dem nächsten Start aktiv.
Sie können die E/A-Überprüfung auch aktivieren und deaktivieren, ohne den Computer neu zu starten, indem Sie dem Befehl den Parameter /volatile hinzufügen. Beispiel:
verifier /volatile /flags 0x10 /adddriver MyDriver.sys
Diese Einstellung ist sofort wirksam, geht aber verloren, wenn Sie den Computer herunterfahren oder neu starten. Ausführliche Informationen finden Sie unter Verwenden flüchtiger Einstellungen.
Die E/A-Überprüfungsfunktion ist auch in den Standardeinstellungen enthalten. Beispiel:
verifier /standard /driver MyDriver.sys
Verwenden des Treiberüberprüfungs-Managers
- Wählen Sie Benutzerdefinierte Einstellungen erstellen (für Codeentwickler) aus, und klicken Sie dann auf Weiter.
- Wählen Sie Einzelne Einstellungen aus einer vollständigen Liste auswählen aus.
- Wählen Sie E /A-Überprüfung (überprüfen) aus.
Die E/A-Überprüfungsfunktion ist auch in den Standardeinstellungen enthalten. Um dieses Feature zu verwenden, klicken Sie im Treiberüberprüfungs-Manager auf Standardeinstellungen erstellen.
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für