Brak sprawdzenia stanu kierowcy

W poniższym przykładzie sterownik używa makra ASSERT do sprawdzania prawidłowego stanu urządzenia w wersji debugowania obrazu sterownika, ale nie sprawdza stanu urządzenia w kompilacji detalicznej tego samego źródła sterownika:

   case IOCTL_WAIT_FOR_EVENT:

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

Jeśli na obrazie debugowania sterownika sterownik już przechowuje oczekujące IRP, system zgłosi asercję. Jednak w kompilacji detalicznej sterownik nie sprawdza tego błędu. Dwa wywołania tego samego IOCTL powodują, że sterownik traci kontrolę nad IRP.

W systemie wieloprocesorowym ten fragment kodu może powodować dodatkowe problemy. Załóżmy, że po wejściu ta rutyna ma własność (prawo do manipulowania) obiektu IRP. Gdy rutyna zapisuje wskaźnik Irp w strukturze globalnej w Extension->WaitEventIrp, inny wątek może uzyskać adres IRP z tej globalnej struktury i wykonywać operacje na IRP. Aby zapobiec temu problemowi, sterownik powinien oznaczyć IRP jako oczekujące przed jego zapisaniem i powinien zawierać zarówno wywołanie funkcji IoMarkIrpPending, jak i przypisanie w sekwencji synchronizowanej. Może być również konieczna rutyna Anulowania dla protokołu IRP.