Dela via

Test- och felsökningsverktyg för Process Lifetime Management (PLM)

En av de viktigaste skillnaderna mellan UWP-appar och traditionella skrivbordsprogram är att UWP-titlar finns i en appcontainer som omfattas av Process Lifecycle Management (PLM). UWP-appar kan pausas, återupptas eller avslutas på alla plattformar av Runtime Broker-tjänsten, och det finns dedikerade verktyg som du kan använda för att framtvinga dessa övergångar när du testar eller felsöker koden som hanterar dem.

Funktioner i Visual Studio 2015

Det inbyggda felsökningsprogrammet i Visual Studio 2015 kan hjälpa dig att undersöka potentiella problem när du använder UWP-exklusiva funktioner. Du kan sätta din applikation i olika PLM-tillstånd med hjälp av verktygsfältet Livscykelhändelser, som blir synligt när du kör och felsöker programmet.

Livscykelhändelser verktygsfält

PLMDebug-verktyget

PLMDebug.exe är ett kommandoradsverktyg som gör att du kan styra PLM-tillståndet för ett programpaket och levereras som en del av Windows SDK. När det har installerats finns verktyget i C:\Program Files (x86)\Windows Kits\10\Debuggers\x64 som standard.

MED PLMDebug kan du också inaktivera PLM för alla installerade apppaket, vilket är nödvändigt för vissa felsökningsprogram. Om du inaktiverar PLM hindras Runtime Broker-tjänsten från att avsluta din app innan du kan felsöka den. Om du vill inaktivera PLM använder du växeln /enableDebug följt av fullständiga paketnamnet för UWP-appen (det korta namnet, paketfamiljenamnet eller AUMID för ett paket fungerar inte):

plmdebug /enableDebug [PackageFullName]

När du har distribuerat UWP-appen från Visual Studio visas det fullständiga paketnamnet i utdatafönstret. Du kan också hämta det fullständiga paketnamnet genom att köra Get-AppxPackage i en PowerShell-konsol.

Att köra Get-AppxPackage

Du kan också ange en absolut sökväg till ett felsökningsprogram som startas automatiskt när apppaketet aktiveras. Om du vill göra detta med Visual Studio måste du ange VSJITDebugger.exe som felsökningsprogram. Men VSJITDebugger.exe kräver att du anger växeln "-p" tillsammans med process-ID (PID) för UWP-appen. Eftersom det inte går att känna till PID för UWP-appen i förväg är det här scenariot inte möjligt direkt.

Du kan kringgå den här begränsningen genom att skriva ett skript eller verktyg som identifierar spelets process, och sedan körs gränssnittet VSJITDebugger.exeoch skickar in PID för din UWP-app. Följande C#-kodexempel illustrerar en enkel metod för att åstadkomma detta.

using System.Diagnostics;

namespace VSJITLauncher
{
    class Program
    {
        static void Main(string[] args)
        {
            // Name of UWP process, which can be retrieved via Task Manager.
            Process[] processes = Process.GetProcessesByName(args[0]);

            // Get PID of most recent instance
            // Note the highest PID is arbitrary. Windows may recycle or wrap the PID at any time.
            int highestId = 0;
            foreach (Process detectedProcess in processes)
            {
                if (detectedProcess.Id > highestId)
                    highestId = detectedProcess.Id;
            }

            // Launch VSJITDebugger.exe, which resides in C:\Windows\System32
            ProcessStartInfo startInfo = new ProcessStartInfo("vsjitdebugger.exe", "-p " + highestId);
            startInfo.UseShellExecute = true;

            Process process = new Process();
            process.StartInfo = startInfo;
            process.Start();
        }
    }
}

Exempel på användning av detta tillsammans med PLMDebug:

plmdebug /enableDebug 279f7062-ce35-40e8-a69f-cc22c08e0bb8_1.0.0.0_x86__c6sq6kwgxxfcg "\"C:\VSJITLauncher.exe\" Game"

där Game är processnamnet och 279f7062-ce35-40e8-a69f-cc22c08e0bb8_1.0.0.0_x86__c6sq6kwgxxfcg är det fullständiga paketnamnet för UWP-exempelapppaketet.

Observera att varje anrop till /enableDebug måste kopplas senare till ett annat PLMDebug-anrop med växeln /disableDebug. Dessutom måste sökvägen till ett felsökningsprogram vara absolut (relativa sökvägar stöds inte).