Partager via

Suppression des co-installateurs des packages de pilotes

  • Article

Attention

À compter de janvier 2023, les paquets de pilotes contenant un co-installateur ne sont plus signés par le portail du Centre matériel de développement . Pour les détails de l'exigence, veuillez vous référer aux spécifications et politiques du programme de compatibilité matérielle Windows , en particulier aux politiques de la version 22H2, section Device.DevFund.INF.Declarative.

Cette page traite des raisons courantes pour lesquelles les co-programmes d’installation doivent être présents dans un package de pilotes et propose des mécanismes permettant d’effectuer la même tâche sans co-programme d’installation.

Co-installateurs WDF et WinUSB

Le co-programme d’installation WDF et le co-programme d’installation WinUSB ne sont pas requis sur un système exécutant Windows 10 et versions ultérieures. Les références du programme de co-installation WDF peuvent être supprimées sans travail supplémentaire. Les références du co-installateur WinUSB peuvent être supprimées, et WinUSB doit être référencée dans le paquet de pilotes INF en utilisant les directives Include et Needs.

Conseils pour le package de pilotes WinUSB

Installation de logiciels présentant l’interface utilisateur

Au lieu de lancer une application pendant une installation, fournissez une application de plateforme Windows universelle installée à l’aide d’une directive AddSoftware à partir d’une section DDInstall.Software du package de pilotes INF.

Pour plus d’informations, voir Associer un pilote à une application Universal Windows Platform (UWP). Une directive AddSoftware est prise en charge sur Windows 10, version 1703 et versions ultérieures de Windows.

Pour plus d’informations, consultez Installation du logiciel associé ci-dessous.

Définition de noms conviviaux pour les appareils

Fichier INF

Un package de pilote INF peut définir le nom convivial de l'appareil comme suit :

[DDInstall.HW]
AddReg = FriendlyName_AddReg

[FriendlyName_AddReg]
HKR,,FriendlyName,, "Device Friendly Name"

Durée

Le nom convivial peut être défini par le pilote pendant l'IRP de démarrage ou la phase PrepareHardware en définissant la propriété DEVPKEY_Device_FriendlyName à l'aide de l'une des API suivantes :

Autres paramètres/configurations d’appareil

Lorsque cela est possible, le pilote peut modifier les paramètres et la configuration de l'appareil au cours de l'IRP de démarrage du pilote ou de la phase PrepareHardware. Lors de la modification de l'état au moment de l'exécution, le pilote doit respecter les exigences d'isolation du package du pilote. Ces exigences fournissent des conseils sur la configuration du pilote et la disposition de l'état et aident à rendre le pilote plus résilient aux modifications externes, plus facile à mettre à jour et plus simple à installer.

Pour les paramètres et la configuration qui ne peuvent pas être définis dans le pilote lui-même, un package de pilotes peut également inclure des composants d’exécution en mode utilisateur qui modifient les paramètres et la configuration. Il peut s’agir d’une application orientée utilisateur ou d’un service Win32 qui met à jour la configuration. Pour plus d’informations sur la façon d’inclure des logiciels en mode utilisateur à utiliser avec un appareil, consultez Utilisation d’un fichier INF de composant.

Si un composant persistant tel qu’un service est utilisé, assurez-vous que ses fonctionnalités sont nécessaires et ne peuvent pas être effectuées de manière moins gourmande en ressources, comme dans un package de pilotes INF ou dans le pilote lui-même. Pour plus d’informations sur la façon de s’assurer qu’un service s’exécute uniquement lorsque des appareils pertinents sont connectés, consultez Déclencheurs de service, services Win32 qui interagissent avec les appareilset Inscription pour les notifications d’interface d’appareil. Le service doit également répondre aux exigences les plus récentes, par exemple en passant le Validateur d’API .

Installation du logiciel associé

La partie « Componentized » des exigences du pilote DCH a introduit un concept appelé SoftwareComponent, qui est un mécanisme permettant de dissocier l’installation d’un pilote de périphérique à partir de son logiciel associé. Quand un composant logiciel est créé par l'INF, il crée automatiquement un périphérique enfant mappé au composant logiciel. Cet appareil enfant existe à des fins d’installation du logiciel associé à l’appareil parent. Ce logiciel peut être installé et mis à jour indépendamment du périphérique principal et du pilote.

Dans un package de pilotes SoftwareComponent INF, le mécanisme recommandé pour installer des logiciels utilise une directive AddSoftware. Cela déclenche le téléchargement et l’installation de logiciels à partir du Windows Store.

Dépendances entre pilotes et appareils

Dépendances de l'ordre de démarrage/d'énumération des appareils

Dans la mesure du possible, les dépendances entre appareils ou les exigences d'ordre de démarrage doivent être évitées.

Pour les appareils énumérés par ACPI, l’objet de dépendance (_DEP) peut être utilisé dans le microprogramme ACPI pour appliquer l’ordre de démarrage de l’appareil. Pour plus d'informations, voir l'espace de noms de la gestion des appareils.

Les pilotes peuvent répondre à l'IRP_MN_QUERY_DEVICE_RELATIONS pour définir les relations entre les appareils, telles que les relations de retrait. Pour plus d'informations, voir IRP_MN_QUERY_DEVICE_RELATIONS.

Dépendances liées à l'installation des packages de pilotes

La directive CopyInf peut également être utilisée pour installer un package de pilotes supplémentaire pendant le même appel d’API d’installation qu’un autre pilote. Le package de pilotes transmis à l’API d’installation est installé avant les packages de pilotes référencés par CopyInf, mais les packages de pilotes référencés par CopyInf ne sont pas garantis d’être installés dans un ordre particulier.

Configuration des composants à partir de plusieurs fournisseurs groupés dans un package de pilotes unique

Les packages de pilotes prennent en charge un type d'INF de package de pilotes appelé INF d'extension. Il s’agit d’un fichier INF spécifiquement conçu pour augmenter et étendre les fonctionnalités d’un fichier INF du package de pilotes « base ». Une extension peut ne pas fournir le pilote de fonction pour l’appareil, mais peut utiliser d’autres directives ou écrire d’autres paramètres pour un appareil. Pendant l’installation d’un pilote, un seul INF du package de pilotes de base est sélectionné à l’aide du classement des pilotes pour fournir les fonctionnalités de l’appareil, puis les INF d’extension sont sélectionnées pour l’appareil. Pour plus d’informations, consultez Utilisation d’un fichier INF d’extension.

Un paradigme courant pour l'utilisation des INF d'extension des packages de pilotes consiste pour le fabricant de matériel à fournir l'INF de base du package de pilotes, et pour un OEM qui expédie cette pièce dans un système à créer un INF d'extension du package de pilotes qui le personnalise pour ce système.

Installation/orchestration des mises à jour du microprogramme

Différents mécanismes de mise à jour du microprogramme sont recommandés en fonction de la nature de l’appareil mis à jour. Chacun des éléments suivants peut être utilisé pour expédier et installer une mise à jour du microprogramme via Windows Update.

Non amovible

La plateforme de mise à jour du microprogramme UEFI est conçue pour mettre à jour les composants d’un système qui ne peuvent pas être supprimés, tels que le microprogramme système. Pour plus d'informations, voir Plate-forme de mise à jour des microprogrammes UEFI

Amovible

Pour les appareils amovibles tels que les périphériques HID ou USB, le modèle CFU permet des mises à jour de microprogramme sécurisées. Pour plus d'informations, voir Mise à jour des microprogrammes des composants.

Implémentation personnalisée

Vous pouvez également écrire un pilote personnalisé qui met à jour le microprogramme de l’appareil à la discrétion du pilote. Pour plus d'informations, voir Pilote de mise à jour du microprogramme personnalisé.