Freigeben über

Grundlegendes zur statischen Treiberüberprüfung

  • Artikel

Um einen robusten Treiber zu schreiben, der dem Windows-Treibermodell (WINDOWS Driver Model, WDM) oder dem Kernel Mode Driver Framework (KMDF), NDIS oder Storport entspricht, müssen Sie über Kenntnisse verfügen und verstehen, wie der Treiber mit dem E/A-Manager interagiert. Das Testen dieser Treiber ist ebenso schwierig.

Die Entwicklung solider Treiber kann aus folgenden Gründen herausfordernd sein:

  • Treiber sind asynchron, auch auf Einzelprozessorcomputern.

  • Treiber werden massiv wiederholt.

  • Treiber verwenden viele verdeckte Regeln.

  • Treibermodelle sind evolutionär und altern im Laufe der Zeit.

Das Testen von Gerätetreibern ist aus den folgenden Gründen eingeschränkt:

  • Beobachtung. Sie können keinen Fehler bei der Interaktion zwischen dem Treiber und dem Betriebssystem beobachten. Treiber können implizite Verwendungsregeln verletzen, was zu einem Absturz oder einem fehlerhaften Verhalten führt, aber es ist schwierig, die Ursache eines Fehlers beim Entwickeln und Testen von Treibern zu erkennen.

  • Kontrolle. Treiber, die unter normalen Umständen ordnungsgemäß funktionieren, können subtile Fehler aufweisen, die nur in Außergewöhnlichen Situationen auftreten, z. B. wenn ein Treiber darunter im Stapel ein IRP fehlschlägt. Solche Situationen sind schwierig zu üben, sodass herkömmliche Tests die Fehlerpfade nicht über den Treibercode angemessen erkennen.

SDV verbessert sowohl die Beobachtung als auch die Kontrolle, die Sie beim Testen von Treibern haben. Indem Sie Regeln für die ordnungsgemäße Verwendung von WDM-, KMDF-, NDIS- und Storport-Funktionen definieren und die Einhaltung dieser Regeln überwachen, verbessert SDV ihre Fähigkeit, Fehler zu beobachten. Beispielsweise gibt die WDM-Regel LowerDriverReturn an, dass unter bestimmten Umständen die Verteilerroutine eines Treibers immer den Wert zurückgeben sollte, der vom unteren Treiber im Stapel zurückgegeben wurde.

SDV erhöht auch die Kontrolle, indem Folgendes bereitgestellt wird:

  • Ein feindliches Modell der Umgebung des Treibers, bei dem mehrere Szenarios im schlimmsten Fall (z. B. Betriebssystemaufrufe, die ständig fehlschlagen) auftreten können.

  • Leistungsstarke statische Analyse (als Modellüberprüfung bezeichnet), die systematisch alle möglichen Ausführungspfade im Treiber untersucht.

SDV ist ein wesentliches Komponententesttool für Gerätetreiber. Er platziert einen Treiber in einer feindlichen Umgebung und testet codepfade systematisch durch den Treiber, indem er nach Verstößen gegen die Nutzungsregeln des Treibermodells sucht.

Wichtig

SDV wird nicht mehr unterstützt, und SDV ist in Windows 24H2 WDK- oder EWDK-Versionen nicht verfügbar. Sie ist in WDKs neuer als Build 26017 nicht verfügbar und nicht im Windows 24H2 RTM WDK enthalten. SDV kann weiterhin verwendet werden, indem Sie das Windows 11, Version 22H2 EWDK (veröffentlicht am 24. Oktober 2023) mit Visual Studio-Buildtools 17.1.5 aus dem Windows Driver Kit (WDK) herunterladen. Es wird nur die Verwendung von Enterprise WDK zum Ausführen von SDV empfohlen. Die Verwendung älterer Versionen des Standard-WDK in Verbindung mit den letzten Versionen von Visual Studio wird nicht empfohlen, da dies wahrscheinlich zu Analysefehlern führt.
In Zukunft wird CodeQL das primäre statische Analysetool für Treiber sein. CodeQL stellt eine leistungsstarke Abfragesprache bereit, die Code als abgefragte Datenbank behandelt, sodass Abfragen für bestimmte Verhaltensweisen, Muster und vieles mehr einfach geschrieben werden können. Weitere Informationen zur Verwendung von CodeQL finden Sie unter CodeQL und dem Logotest für statische Tools.