Freigeben über

Fehler beim Überprüfen des Treiberstatus

  • Artikel

Im folgenden Beispiel sucht der Treiber mithilfe des ASSERT-Makros nach dem richtigen Gerätestatus in einer Debugversion eines Treiberimages, ü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 Debugtreiberimage bereits die ausstehende IRP enthält, wird vom System behauptet. In einem Einzelhandelsbuild sucht der Treiber jedoch nicht auf diesen Fehler. Zwei Aufrufe an dieselbe IOCTL führen dazu, dass der Treiber den Überblick über ein IRP verliert.

Auf einem Multiprozessorsystem kann dieses Codefragment zusätzliche Probleme verursachen. Angenommen, diese Routine besitzt beim Eintrag den Besitz (das Recht, diese IRP zu bearbeiten). 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 vermeiden, sollte der Treiber das IRP ausstehend markieren, bevor er das IRP speichert, und sowohl den Aufruf von IoMarkIrpPending als auch die Zuweisung in einer ineinandergreifenden Sequenz einschließen. Möglicherweise ist auch eine Cancel-Routine für die IRP erforderlich.