Falha ao verificar o estado de um driver

  • Artigo

No exemplo a seguir, o driver usa a macro ASSERT para marcar para o estado correto do dispositivo em uma versão de depuração de uma imagem de driver, mas não marcar 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á mantiver o IRP pendente, o sistema afirmará. Em uma compilação de varejo, no entanto, o driver não marcar para 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, na entrada, 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 pendente antes de salvar o IRP e deve incluir a chamada para IoMarkIrpPending e a atribuição em uma sequência interconectada. Uma rotina cancelar para o IRP também pode ser necessária.