Falha na verificação do estado de um condutor

No exemplo a seguir, o driver usa a macro ASSERT para verificar o estado correto do dispositivo em uma versão de depuração de uma imagem de driver, mas não verifica o estado do dispositivo na compilação de varejo da mesma fonte de driver:

   case IOCTL_WAIT_FOR_EVENT:

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

Na imagem do driver de depuração, se o driver já tiver o IRP pendente, o sistema gerará uma asserção. Em uma compilação de varejo, no entanto, o driver não verifica esse erro. Duas chamadas para o mesmo IOCTL fazem com que o motorista perca o controle de um IRP.

Em um sistema multiprocessador, esse fragmento de código pode causar problemas adicionais. Suponha que, ao iniciar, esta rotina tem a propriedade de (o direito de manipular) este IRP. Quando a rotina salva o ponteiro Irp na estrutura global em Extension-WaitEventIrp>, outra thread pode obter o endereço IRP dessa estrutura global e executar operações no IRP. Para evitar este problema, o driver deve marcar o IRP como pendente antes de o guardar e incluir a chamada para IoMarkIrpPending e a atribuição em sequência sincronizada. Uma rotina de cancelamento para o IRP também pode ser necessária.