Falha ao verificar o estado de um driver

No exemplo a seguir, o driver usa a macro ASSERT para verificar o estado correto do dispositivo em uma imagem de driver na sua versão de depuração, mas não verifica o estado do dispositivo na versão para venda 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á mantiver o IRP pendente, o sistema afirmará. Em uma versão de varejo, no entanto, o driver não verifica esse erro. Duas chamadas para o mesmo IOCTL fazem com que o driver perca o controle de um IRP.

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