Freigeben über


Automatische Kontrollen

Die Treiberüberprüfung führt die folgenden Überprüfungen aus, wenn ein oder mehrere Treiber überprüft werden. Sie können diese Prüfungen nicht aktivieren oder deaktivieren. Ab Windows 10, Version 1709, wurden diese automatischen Prüfungen in relevante Standardkennzeichnungen verschoben. Daher sollten Benutzer, die "Driver Verifier" mit den Standardkennzeichnungen aktivieren, keine Reduzierung der Prüfungen sehen.

Überwachen von IRQL- und Speicherroutinen

Driver Verifier überwacht den ausgewählten Treiber auf die folgenden verbotenen Aktionen:

  • Erhöhen der IRQL durch Aufruf von KeLowerIrql

  • Senken von IRQL durch Aufrufen von KeRaiseIrql

  • Anfordern einer Speicherzuweisung der Größe Null

  • Zuweisen oder Freigeben von seitenseitigem Pool mit IRQL-APC_LEVEL >

  • Zuweisen oder Freigeben eines nicht seitenfreien Pools mit IRQL-DISPATCH_LEVEL >

  • Versuchen, eine Adresse freizumachen, die nicht bei einer vorherigen Zuordnung zugewiesen wurde

  • Versuchen Sie, eine Adresse freizugeben, die bereits freigegeben wurde

  • Abrufen oder Freigeben eines schnellen Mutex bei IRQL > APC_LEVEL

  • Abrufen oder Freigeben einer Drehsperre mit IRQL ist nicht gleich DISPATCH_LEVEL

  • Doppelte Freigabe eines Spinlocks.

  • Eine Zuordnungsanforderung als 'MUST_SUCCEED' markieren. Solche Anfragen sind niemals zulässig.

Wenn die Treiberüberprüfung nicht aktiv ist, verursachen diese Verletzungen möglicherweise nicht in allen Fällen einen sofortigen Systemabsturz. Driver Verifier überwacht das Verhalten des Treibers und meldet einen Bug Check 0xC4, wenn einer dieser Verstöße auftritt. Eine Liste der Fehlerüberprüfungsparameter finden Sie unter "Fehlerüberprüfung 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION)".

Überwachen des Stackwechsels

Driver Verifier überwacht die Stapelnutzung des überprüften Treibers. Wenn der Treiber seinen Stapel wechselt und der neue Stapel weder ein Threadstapel noch ein DPC-Stapel ist, wird eine Fehlerüberprüfung ausgegeben. (Dies ist die Fehlerüberprüfung 0xC4 mit dem ersten Parameter gleich 0x90.) Der vom KB-Debuggerbefehl angezeigte Stapel zeigt in der Regel den Treiber an, der diesen Vorgang ausgeführt hat.

Überprüfung des Entladens des Treibers

Nachdem ein Treiber, der überprüft wird, entladen wird, führt die Treiberüberprüfung mehrere Überprüfungen durch, um sicherzustellen, dass der Treiber bereinigt wurde.

Insbesondere sucht Driver Verifier nach:

  • Nicht gelöschte Timer

  • Ausstehende aufgeschobene Prozeduraufrufe (DPCs)

  • Nicht gelöschte Lookaside-Listen

  • Nicht gelöschte Worker-Threads

  • Nicht gelöschte Warteschlangen

  • Andere ähnliche Ressourcen

Solche Probleme können dazu führen, dass Systemprüfungen auf Fehler kurze Zeit nach dem Entladen des Treibers durchgeführt werden, und die Ursache dieser Überprüfungen kann schwer zu ermitteln sein. Wenn der Driver Verifier aktiv ist, wird der Fehlerüberprüfungscode 0xC7 unmittelbar nach dem Entladen des Treibers ausgegeben. Eine Liste der Fehlerüberprüfungsparameter finden Sie unter "Fehlerüberprüfung 0xC7 (TIMER_OR_DPC_INVALID)".

Überwachen der Speicherdeskriptorliste (MDL)-Verwendung

In Windows Vista überwacht Driver Verifier auch den ausgewählten Treiber auf die folgenden verbotenen Aktionen:

  • Aufrufen von MmProbeAndLockPages oder MmProbeAndLockProcessPages für eine MDL, die nicht über die entsprechenden Flags verfügt. Beispielsweise ist es falsch, MmProbeAndLockPages für eine MDL aufzurufen, die mithilfe von MmBuildMdlForNonPagedPool erstellt wurde.

  • Aufrufen von MmMapLockedPages für eine MDL, die nicht über die entsprechenden Flags verfügt. Beispielsweise ist es falsch, MmMapLockedPages für eine MDL aufzurufen, die bereits einer Systemadresse oder MDL zugeordnet ist, die nicht gesperrt ist.

  • Aufrufen von MmUnlockPages oder MmUnmapLockedPages für eine partielle MDL, das heißt, eine MDL, die mit IoBuildPartialMdl erstellt wurde.

  • Aufruf von MmUnmapLockedPages auf einem MDL, das keiner Systemadresse zugeordnet ist.

Wenn der Driver Verifier nicht aktiv ist, könnten diese Verstöße möglicherweise nicht dazu führen, dass das System in allen Fällen sofort nicht mehr reagiert. Driver Verifier überwacht das Verhalten des Treibers und gibt die Fehlerüberprüfung 0xC4 aus, wenn einer dieser Verstöße auftritt. Eine Liste der Fehlerüberprüfungsparameter finden Sie unter "Fehlerüberprüfung 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION)".

Synchronisierungsobjektzuordnung aus nichtpagedPoolSession-Speicher

Ab Windows 7 sucht die Treiberüberprüfung nach Synchronisierungsobjekten aus dem Sitzungsspeicher.

Synchronisierungsobjekte müssen nicht auspagebar sein. Sie müssen auch im globalen, systemweiten virtuellen Adressraum leben.

Ein Grafiktreiber kann Sitzungsspeicher zuordnen, indem APIs wie EngAllocMem aufgerufen werden. Im Gegensatz zum globalen Adressraum wird der Sitzungsadressraum für jede Terminalserversitzung virtualisiert. Dies bedeutet, dass die gleiche virtuelle Adresse, die im Kontext von zwei verschiedenen Sitzungen verwendet wird, auf zwei verschiedene Objekte verweist. Der Windows-Kernel muss über jede Terminalserversitzung auf Synchronisierungsobjekte zugreifen können. Beim Versuch, auf eine Sitzungsspeicheradresse aus einer anderen Sitzung zu verweisen, ergeben sich unvorhersehbare Ergebnisse, z. B. Systemabstürzen oder automatische Beschädigung der Daten einer anderen Sitzung.

Ab Windows 7, wenn ein verifizierter Treiber ein Synchronisierungsobjekt durch Aufrufen von APIs wie KeInitializeEvent oder KeInitializeMutex initialisiert, überprüft der Driver Verifier, ob die Adresse des Objekts im virtuellen Adressraum der Sitzung liegt. Wenn Driver Verifier diese Art von falscher Adresse erkennt, wird eine Fehlerüberprüfung 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION mit einem Parameter 1-Wert von 0xDF ausgegeben.

Objektverweiszähleränderungen von 0 zu 1

Ab Windows 7 sucht die Treiberüberprüfung nach zusätzlichen Klassen falscher Objektverweise.

Wenn der Windows-Kernelobjekt-Manager ein Objekt erstellt, z. B. ein File-Objekt oder ein Thread-Objekt, wird der Verweiszähler des neuen Objekts auf 1 festgelegt. Der Verweiszähler wird durch Aufrufe von APIs wie ObReferenceObjectByPointer oder ObReferenceObjectByHandle erhöht. Der Verweiszähler wird von jedem ObDereferenceObject-Aufruf für dasselbe Objekt verringert.

Nachdem der Bezugszähler den Wert 0 erreicht hat, kann das Objekt freigegeben werden. Der Objektmanager kann es sofort freigeben oder später freigeben. Das Aufrufen von ObReferenceObjectByPointer oder ObDereferenceObject und das Ändern des Verweiszählers von 0 auf 1 bedeutet, dass der Verweiszähler eines bereits freigegebenen Objekts erhöht wird. Dies ist immer falsch, da die Speicherzuweisung einer anderen Person beschädigt werden kann.

Systemabschaltung blockiert oder verzögert

Ab Windows 7, löst Driver Verifier einen Haltepunkt im Kernel-Debugger aus, wenn das Herunterfahren des Systems nicht 20 Minuten nach dem Start beendet wird. Driver Verifier weist den Start des Systemherunterfahrens als Zeitpunkt zu, zu dem der Windows-Kernel mit dem Herunterfahren seiner verschiedenen Subsysteme beginnt, z. B. Registry, Plug And Play oder die I/O-Manager-Subsysteme.

Wenn kein Kernel-Debugger an das System angefügt ist, gibt Driver Verifier eine Fehlerprüfung 0xC4 aus: DRIVER_VERIFIER_DETECTED_VIOLATION mit einem Parameterwert 1 von 0x115 anstelle dieses Haltepunkts.

Häufig zeigt ein Herunterfahren des Systems, das nicht in weniger als 20 Minuten abgeschlossen werden kann, an, dass einer der Treiber, die auf diesem System ausgeführt werden, nicht ordnungsgemäß funktioniert. Wenn !analyze -v aus dem Kerneldebugger ausgeführt wird, wird der Stack-Trace des Systemarbeitsthreads angezeigt, der für das Herunterfahren verantwortlich ist. Sie sollten diese Stack-Trace untersuchen, und ermitteln, ob der Shutdown-Thread von einem der getesteten Treiber blockiert wird.

Manchmal kann das System nicht heruntergefahren werden, da es stark stresstests unterzogen wird, auch wenn alle Treiber ordnungsgemäß funktionieren. Der Benutzer kann die Ausführung nach diesem Driver Verifier-Haltepunkt fortsetzen und überprüfen, ob das System schließlich heruntergefahren wird.