Partager via

Avantages de l’écriture de pilotes UMDF

  • Article

Cette rubrique décrit les avantages de l’écriture d’un pilote UMDF (User-Mode Driver Framework) au lieu d’un pilote en mode noyau.

Lorsque vous écrivez un pilote UMDF, vous bénéficiez des éléments suivants :

  • Les pilotes UMDF contribuent à une plus grande stabilité du système d’exploitation, car ils n’ont accès qu’à l’espace d’adressage du processus dans lequel ils s’exécutent.

  • Étant donné que les pilotes UMDF s’exécutent sous le compte LocalService , ils ont un accès limité aux données d’un utilisateur ou aux fichiers système.

  • Les pilotes en mode utilisateur fonctionnent dans un environnement beaucoup plus simple que les pilotes en mode noyau. Par exemple, les pilotes en mode noyau doivent prendre en compte l’IRQL, les erreurs de page et le contexte de thread. Toutefois, en mode utilisateur, ces problèmes n’existent pas. Les pilotes en mode utilisateur s’exécutent toujours dans un thread différent du processus demandeur et peuvent toujours prendre des erreurs de page.

  • UMDF version 2 offre la parité des fonctionnalités avec KMDF dans la plupart des régions. Pour une comparaison complète, consultez Comparaison des fonctionnalités UMDF 2 à KMDF.

  • UMDF version 2 facilite la conversion entre KMDF et UMDF. Consultez Comment convertir un pilote KMDF en pilote UMDF 2 (et inversement).

  • Vous pouvez déboguer des pilotes UMDF à l’aide d’un débogueur en mode utilisateur ou, à partir d’UMDF version 2, d’un débogueur en mode noyau.

  • Vous pouvez utiliser les commandes d’extension de débogueur Wdfkd.dll avec KMDF et à partir d’UMDF version 2. Pour plus d’informations, consultez Extensions de débogueur.

Un objectif fondamental du modèle WDF global est de fournir des valeurs par défaut intelligentes, afin que vous puissiez vous concentrer sur le matériel de votre appareil et éviter d’écrire du code pour effectuer des tâches communes à la plupart des pilotes.

Pour atteindre cet objectif, le framework est conçu pour fonctionner avec les pilotes sur une base « d’adhésion ». Lorsque vous écrivez un pilote UMDF, vous fournissez des routines de rappel uniquement pour les événements qui affectent votre appareil. Par exemple, certains appareils nécessitent une intervention immédiatement après leur activation et juste avant leur désactivation. Le pilote d’un tel appareil peut implémenter des fonctions de rappel que l’infrastructure appelle à ce moment-là.

Le pilote inclut du code pour gérer uniquement les événements pour lesquels son appareil nécessite une prise en charge spécifique à l’appareil. Tous les autres événements peuvent être gérés par défaut du framework.

En outre, un pilote peut configurer ses files d’attente de demandes d’E/S afin que l’infrastructure arrête la distribution des demandes lorsque l’appareil est à faible consommation d’énergie et reprenne la distribution une fois que l’appareil est revenu à l’état opérationnel. De même, si une demande d’E/S arrive alors que l’appareil est à faible consommation d’énergie, l’infrastructure peut automatiquement activer l’appareil.