Échec de la validation des objets d’appareil

De nombreux pilotes créent plusieurs types d’objets d’appareil en appelant IoCreateDevice. Certains pilotes créent des objets de périphérique de contrôle dans leurs routines DriverEntry pour permettre aux applications de communiquer avec le pilote, avant même que le pilote crée un FDO. Par exemple, les pilotes de système de fichiers créent des objets de périphérique pour gérer les notifications du système de fichiers lorsqu’ils s’inscrivent eux-mêmes en tant que systèmes de fichiers avec IoRegisterFileSystem.

Un pilote doit être prêt pour les demandes IRP_MJ_CREATE pour tout objet de périphérique qu’il crée. Une fois la demande terminée avec une status réussie, le pilote doit s’attendre à recevoir toutes les demandes d’E/S accessibles à l’utilisateur sur l’objet de fichier créé. Par conséquent, tout pilote qui crée plusieurs objets de périphérique doit case activée l’objet de périphérique spécifié par chaque demande d’E/S.

Par exemple, supposons qu’un pilote crée des objets de périphérique de contrôle global dans DriverEntry, puis crée un autre ensemble d’objets de périphérique dans sa routine AddDevice . Supposons que la routine AddDevice initialise l’extension de périphérique avec des informations sur les pilotes de niveau inférieur, mais que les objets de périphérique de contrôle ne contiennent pas ces informations. Dans ce cas, toutes les routines de distribution doivent veiller à case activée chaque objet d’appareil qu’elles reçoivent. Sinon, le pilote risque de se bloquer lors de la tentative d’utilisation des informations d’extension de périphérique.