Fehler beim Überprüfen des Zustands eines Fahrers

Im folgenden Beispiel verwendet der Treiber das ASSERT-Makro , um in einer Debugversion eines Treiberimages nach dem richtigen Gerätezustand zu suchen, überprüft jedoch nicht den Gerätestatus im Einzelhandelsbuild derselben Treiberquelle:

   case IOCTL_WAIT_FOR_EVENT:

      ASSERT((!Extension->WaitEventIrp));
      Extension->WaitEventIrp = Irp;
      IoMarkIrpPending(Irp);
      status = STATUS_PENDING;

Wenn der Treiber im Debug-Treiberabbild bereits das IRP bearbeitet, löst das System eine Assertion aus. In einem Einzelhandelsbuild wird der Treiber jedoch nicht auf diesen Fehler überprüft. Zwei Aufrufe an dieselbe IOCTL führen dazu, dass der Treiber die Spur eines IRP verliert.

In einem Multiprozessorsystem kann dieses Codefragment zusätzliche Probleme verursachen. Angenommen, dass diese Routine beim Eintritt die Verantwortung für die Bearbeitung dieses IRP besitzt. Wenn die Routine den Irp-Zeiger in der globalen Struktur bei Extension-WaitEventIrp> speichert, kann ein anderer Thread die IRP-Adresse aus dieser globalen Struktur abrufen und Vorgänge für das IRP ausführen. Um dieses Problem zu verhindern, sollte der Treiber das ausstehende IRP markieren, bevor das IRP gespeichert wird, und sowohl den Aufruf von IoMarkIrpPending als auch die Zuordnung in einer verriegelten Sequenz enthalten. Möglicherweise ist auch eine Cancel-Routine für das IRP erforderlich.