Échec de la vérification de l’état d’un pilote

Dans l’exemple suivant, le pilote utilise la macro ASSERT pour rechercher l’état correct de l’appareil dans une version de débogage d’une image de pilote, mais ne vérifie pas l’état de l’appareil dans la build commerciale de la même source de pilote :

   case IOCTL_WAIT_FOR_EVENT:

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

Dans l’image du pilote de débogage, si le pilote contient déjà l’IRP en attente, le système va donner une assertion. Dans une version pour le marché de détail, toutefois, le pilote ne vérifie pas cette erreur. Deux appels au même IOCTL entraînent le pilote à perdre la trace d'un IRP.

Sur un système multiprocesseur, ce fragment de code peut entraîner des problèmes supplémentaires. Supposons que, lors de l’entrée, cette routine possède (le droit de manipuler) cet IRP. Lorsque la routine enregistre le pointeur Irp dans la structure globale sur Extension-WaitEventIrp>, un autre thread peut obtenir l’adresse IRP à partir de cette structure globale et effectuer des opérations sur l’IRP. Pour éviter ce problème, le pilote doit marquer l’IRP en attente avant d’enregistrer l’IRP et doit inclure à la fois l’appel à IoMarkIrpPending et l’affectation dans une séquence interblocée. Une routine d’annulation pour l’IRP peut également être nécessaire.