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

Dans l’exemple suivant, le pilote utilise la macro ASSERT pour case activée l’état correct de l’appareil dans une version de débogage d’une image de pilote, mais ne case activée 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 maintient déjà l’IRP en attente, le système affirme. Dans une build de vente au détail, toutefois, le pilote ne case activée pas pour cette erreur. Deux appels au même IOCTL font 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 a la propriété 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 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 verrouillée. Une routine d’annulation pour l’IRP peut également être nécessaire.