EvtIddCxMonitorAssignSwapChain-felhantering

Ändringar i hantering av EvtIddCxMonitorAssignSwapChain-fel

I Windows 10-versioner före version 1903 var resten av skrivbordskompositionen omedveten om EvtIddCxMonitorAssignSwapChain misslyckades. Det fortsatte att rendera och presentera bilder som det indirekta visningskortet inte bearbetade, vilket resulterade i att IddCx avslutade den indirekta visningsdrivrutinen (IDD) efter en viss tid.

Från och med Windows 10 version 1903 (IddCx 1.4), ändrades IddCx-felhantering för den här återanropningen för alla drivrutinsversioner och som introducerade statuskoden STATUS_GRAPHICS_INDIRECT_DISPLAY_ABANDON_SWAPCHAIN. Mer information finns i EvtIddCxMonitorAssignSwapChain .

Hantera fel i rambearbetningens loop-thread

När IDD framgångsrikt returnerar från EvtIddCxMonitorAssignSwapChain äger det hSwapChain-objektet. Om drivrutinen stöter på ett fel som hindrar den från att fortsätta bearbeta ramen kan den anropa WdfObjectDelete för att frigöra ägarskap. Operativsystemet identifierar borttagningen och gör att en ny växlingskedja skapas.

Om drivrutinen vet att den inte kan återställas från det här felet bör den anropa IddCxReportCriticalError för att stoppa enheten.

Föreslagen metod för att hantera swapchain-fel

Det finns flera orsaker till fel i EvtIddCxMonitorAssignSwapChain-återanrop eller under bearbetning av bildrutor. Felkategoriseringar inkluderar:

• Tillfälliga problem som är specifika för din lösning, till exempel ett tillfälligt problem med maskinvaran. Den här typen av problem kan åtgärdas med enkla återställningsmekanismer som inte påverkar användarupplevelsen eftersom återställningen sker snabbt (vanligtvis långt under en sekund) och inte påverkar det visuella innehållet på skärmen (till exempel inga flimmer).
• Permanenta problem som är specifika för din lösning, till exempel ett dödläge i drivrutinen eller ett allvarligt problem med maskinvaran. Den här typen av problem är vanligtvis svåra att åtgärda snabbt, om det alls går.
• DirectX API-fel som orsakas av händelser utanför drivrutinen. Drivrutinen har till exempel ingen kontroll över händelser som när adaptern där din D3D-enhet ska bearbeta skrivbordsavbildningen var PnpStopped eller när det uppstod ett GPU-omfattande fel och det återställdes.
• DirectX API-fel som orsakas av drivrutinen. Drivrutinsbuggar kan orsaka att D3D-enheten sätts i fel eller låser sig. Om du till exempel anropar CopySubResource med koordinater utanför strukturens gräns försätts enheten i ett feltillstånd.
• DirectX API-fel som orsakas av en annan IHV GPU-drivrutin. Dessa fel kan bero på korrekta anropsmönster i IDD:t som utlöser IHV GPU-drivrutinsbuggar.

Det är svårt för en drivrutin att exakt skilja mellan de olika DirectX-felen. Den största skillnaden är att fel som orsakas av externa DirectX-komponenter sannolikt är tillfälliga och att systemet återställs till ett stabilt tillstånd. Om felet orsakas av den indirekta bildskärmen eller GPU-drivrutinen kommer buggar sannolikt att inträffa igen.

Mer information om hur du sprider dessa fel tillbaka till operativsystemet så att det försöker igen finns i EvtIddCxMonitorAssignSwapChain.

Nedan visas några riktlinjer för hur du hanterar varje typ av fel i drivrutinen.

Tillfälliga problem som är specifika för din lösning

Drivrutinen bör åtgärda problemet medan bildrutan bearbetas. Den här åtgärden kan leda till en liten fördröjning i bearbetningen av ramen. Om felet inträffar regelbundet kan föraren överväga att hantera felet proaktivt som ett kvarstående problem.

Permanenta problem som är specifika för din lösning

Drivrutinen bör anropa IddCxReportCriticalError med en huvudkod som är lika med eller högre än 0x100 och använda unika huvud-/delkoder för att representera typen av fel för att underlätta kund- och telemetriundersökningar.

DirectX-fel

Det enklaste sättet att hantera DirectX-fel är att sprida dem tillbaka till operativsystemet så att det försöker igen. Drivrutinen bör returnera STATUS_GRAPHICS_INDIRECT_DISPLAY_ABANDON_SWAPCHAIN från EvtIddCxMonitorAssignSwapChain, eller, om felet inträffar under bearbetningen av en bildruta, bör drivrutinen släppa swapkedjan genom att anropa WdfObjectDelete.

Den här enkla metoden hanterar fel som utlöses av externa händelser, eftersom operativsystemet stabiliseras och skapar en ny växlingskedja (eventuellt på ett nytt Dxgi-kort). Om drivrutinens användning av DirectX är begränsad fungerar den här metoden bra.

För mer komplexa drivrutiner som kan stöta på DirectX-fel som orsakas av buggar i IDD:t eller för drivrutiner som körs på gamla/buggiga DirectX-drivrutiner kan den här metoden sluta i en oändlig loop med ID-växlingsfel. För att undvika en oändlig loop kan IDD:t övervaka frekvensen för dessa fel och gå igenom återställningsstegen när ett visst stadium har nått tillräckligt många felcykler. Om DirectX-fel påträffas är det viktigt att drivrutinen förstör DX-enheten och skapar en ny, för när en DX-enhet är i ett feltillstånd kommer den aldrig att återställas och behöver återskapas.

Drivrutinen kan till exempel överväga fem på varandra följande DirectX-fel i EvtIddCxMonitorAssignSwapChain eller fem fel vid bearbetning av bildrutor med 1 minut som kriterier för att vidta återställningsåtgärden för den aktuella fasen i tabellen ovan.