Gestion des erreurs EvtIddCxMonitorAssignSwapChain

Modification du traitement des erreurs dans EvtIddCxMonitorAssignSwapChain

Dans les versions de Windows 10 antérieures à la version 1903, le reste de la composition du bureau n’était pas au courant si EvtIddCxMonitorAssignSwapChain avait échoué. Il a continué à afficher et à présenter des images que l’adaptateur d’affichage indirect n’a pas traité, ce qui a entraîné la fin du pilote d’affichage indirect (IDD) après un certain temps.

À partir de Windows 10 version 1903 (IddCx 1.4), le traitement des erreurs IddCx pour ce callback a changé pour toutes les versions de pilotes et a introduit le code d’état STATUS_GRAPHICS_INDIRECT_DISPLAY_ABANDON_SWAPCHAIN. Pour plus d’informations, consultez EvtIddCxMonitorAssignSwapChain .

Gestion des erreurs dans le thread de boucle de traitement d’images

Une fois que l'IDD retourne avec succès de EvtIddCxMonitorAssignSwapChain, il possède l’objet hSwapChain. Si le pilote rencontre une erreur qui l’empêche de continuer à traiter l’image, il peut appeler WdfObjectDelete pour libérer la propriété. Le système d’exploitation détecte la suppression et provoque la création d’une nouvelle chaîne d’échange.

Si le pilote sait qu’il ne peut pas récupérer à partir de cette erreur, il doit appeler IddCxReportCriticalError pour arrêter l’appareil.

Approche suggérée pour gérer les erreurs de swapchain

Il existe plusieurs raisons d'échec dans le callback EvtIddCxMonitorAssignSwapChain ou lors du traitement des images. Les catégorisations d’échec sont les suivantes :

• Problèmes temporaires spécifiques à votre solution, tels qu’un problème temporaire avec le matériel. Ce type de problème peut être résolu avec des mécanismes de récupération légers qui n’affecteront pas l’expérience utilisateur, car la récupération se produit rapidement (généralement bien sous une seconde dans le temps) et n’affectera pas le contenu visuel à l’écran (par exemple, pas de glissement).
• Problèmes permanents spécifiques à votre solution, tels qu’une situation de blocage dans le driver ou un problème sérieux avec le matériel. Ce type de problème ne peut généralement pas être résolu rapidement, voire pas du tout.
• Erreurs d’API DirectX provoquées par des événements externes à votre pilote. Par exemple, votre pilote n’a aucun contrôle sur des événements tels que lorsque l’adaptateur sur lequel votre périphérique D3D doit traiter l’image de bureau a été PnpStopped ou qu'il y a eu une défaillance globale du GPU et qu'il a été réinitialisé.
• Erreurs d’API DirectX provoquées par votre pilote. Les bogues du pilote peuvent entraîner une erreur ou un blocage du périphérique D3D. Par exemple, l’appel de CopySubResource avec des coordonnées en dehors de la limite de la texture place l’appareil dans un état d’erreur.
• Erreurs d’API DirectX provoquées par un autre pilote GPU IHV. Ces erreurs peuvent être le résultat de modèles d’appel corrects dans l’IDD qui déclenchent des bogues de pilote GPU IHV.

Il est difficile pour un pilote de distinguer avec précision les différentes erreurs DirectX. La principale différence est que les erreurs provoquées par des composants DirectX externes sont susceptibles d’être temporaires et que le système se rétablit dans un état stable ; alors que, si l’erreur est due à l’affichage indirect ou au pilote GPU, les bogues sont susceptibles de se produire à nouveau.

Consultez EvtIddCxMonitorAssignSwapChain pour plus d’informations sur la propagation de ces erreurs au système d’exploitation afin que le système d’exploitation réessaye.

Voici quelques instructions sur la façon de gérer chaque type d’erreur dans votre pilote.

Problèmes temporaires spécifiques à votre solution

Le pilote doit résoudre le problème lors du traitement de l’image. Cette action peut entraîner un petit retard dans le traitement de l’image. Si l'erreur se produit régulièrement, le pilote pourrait envisager de considérer l'erreur comme un problème permanent.

Problèmes permanents spécifiques à votre solution

Le pilote doit appeler IddCxReportCriticalError avec un code principal égal ou supérieur à 0x100 et utiliser des codes uniques principaux/secondaires pour représenter le type d'erreur, afin de faciliter les enquêtes des clients et la télémétrie.

Erreur DirectX

La façon la plus simple de gérer les erreurs DirectX consiste à les propager au système d’exploitation afin qu’elles réessayent. Le pilote doit retourner STATUS_GRAPHICS_INDIRECT_DISPLAY_ABANDON_SWAPCHAIN à partir d’EvtIddCxMonitorAssignSwapChain ou, si l’erreur se produit lors du traitement d’une trame, le pilote doit libérer la chaîne d’échange en appelant WdfObjectDelete.

Cette approche simple gère les erreurs déclenchées par des événements externes, car le système d’exploitation se stabilise et crée une nouvelle chaîne d’échange (éventuellement sur un nouvel adaptateur Dxgi). Si l’utilisation du pilote de DirectX est limitée, cette approche fonctionne bien.

Pour les pilotes plus complexes qui pourraient rencontrer des erreurs DirectX en raison de bogues dans l'IDD ou pour les pilotes fonctionnant avec des pilotes DirectX anciens ou bogués, cette approche pourrait se terminer par une boucle infinie d’échecs de la chaîne d’échange d’ID. Pour éviter une boucle infinie, l’IDD peut surveiller la fréquence de ces erreurs et parcourir les étapes de récupération lorsqu’une étape donnée a atteint suffisamment de cycles d’erreur. Si des erreurs DirectX sont rencontrées, il est important que le pilote détruise cet appareil DX et en crée un, car une fois qu’un appareil DX est dans un état d’erreur, il ne récupérera jamais et doit être recréé.

Par exemple, le pilote peut envisager cinq défaillances DirectX consécutives dans EvtIddCxMonitorAssignSwapChain ou cinq défaillances lors du traitement des trames, avec 1 minute comme critère, pour prendre des mesures de récupération pour l’étape actuelle du tableau ci-dessus.