Så här hittar du och fixar buggar i kommersiell programvara på Windows

enligt Wikipedia är ”ett programfel ett fel, fel, fel eller fel i ett datorprogram eller system som gör att det ger ett felaktigt eller oväntat resultat, eller att bete sig på oavsiktliga sätt, så småningom kraschar programmet. Processen att fixa buggar kallas” felsökning ” och använder ofta formella tekniker eller verktyg för att hitta fel .”

för det mesta kan buggar reproduceras i en utvecklarmiljö och fixas innan de skickar en version till produktion. Men ibland beror buggar på användarnas specifika miljö eller profil—till exempel med hjälp av specialtecken i ett mappnamn—vilket gör det svårare att förstå en Buggs grundorsak. De värsta buggarna kräver användarstöd för att ställa in en screenshare-session för att se en användare reproducera en bugg.

på Dashlane använder Windows-teamet flera verktyg för att hitta och reproducera buggar:

  • tekniska loggar för att upptäcka var problem uppstår och hjälpa till att fixa dem, ibland kräver flera iterationer och interaktion med användaren som upplever ett problem
  • Microsoft Process Monitor och Process Explorer, Två gratis verktyg som identifierar dåliga installationer eller en skadad miljö

nyligen introducerade Microsoft en ny version av ett annat utvecklarverktyg, WinDbg. Denna ansökan portades in i en UWP app, är fritt tillgänglig på Microsoft Store, och kommer med en mycket trevlig och användbar funktion: TTD, eller tidsresor felsökning. Tänk på en tid du var tvungen att fixa en mycket svår att reproducera bugg som bara hände på en specifik maskin. Eller tänk på den tid du spenderade på att installera en utvecklarmiljö på den maskinen—om du kunde. Och tänk sedan på hur många gånger du var tvungen att starta din applikation i felsökningsläge för att reproducera felet, och sedan missade du den skadade raden genom att oavsiktligt slå F5 istället för F11. TTD förvandlar detta till en bit kaka, eftersom du bara behöver spela in felet en gång för att låta dig spela upp det om och om igen, både framåt och bakåt.

tidsresor felsökning med WinDbg

TTD är en omvänd felsökning lösning. Den består av 3 steg:

  1. spela in appen eller processen på maskinen som kan reproducera felet. Använd WinDbg med administratörsrättigheter och starta en körbar, eller bifoga en som redan körs för att spela in sitt spår. Resultatet är en fil (.kör förlängning) som innehåller all information för att reproducera felet. Av denna anledning kan vi på Dashlane bara använda den för att felsöka buggar som händer före inloggning för att inte samla in användarnas känsliga information.
  2. spela upp det inspelade spåret framåt och bakåt så många gånger som nödvändigt för att förstå problemet. En gång laddad skapar WinDbg ett index för spåret, vilket ger fullständig och snabb minnessökning. Den inspelade filen kan laddas på vilken maskin som helst; vi öppnar vanligtvis på en utvecklarmaskin, där vi kan ladda källkod och PDB-symboler. På så sätt kan vi spela upp spåret när vi kör kod i vår IDE med process-och minnesposter från den inspelade maskinen. (Se till att källkoden och symbolerna matchar den inspelade processversionen.)
  3. analysera genom att lägga till brytpunkter, kör frågor för att identifiera vanliga kodproblem och få full tillgång till minne och lokalbefolkningen för att förstå vad som händer.

exempel

Antag att du har skrivit och byggt en enkel konsolapplikation.

void GuiltyFunction(int a, int b, int c)
{
int x = a + b + c;
int y = 0;
y = x / b;
}
int main()
{
int a = 10;
int b = 0;
int c = 3;
GuiltyFunction(a, b, c);
return 0;
}

låt oss anta den inbyggda applikationen (TestTTD.exe) och symbolfilen (TestTTD.pdb) är i C:\TestTTD\bin och källkoden finns i C:\TestTTD\src.

spela in

  1. öppna WinDbg med förhöjda rättigheter.
  2. på fliken Arkiv väljer du starta körbar (avancerad). I det körbara fältet anger du C:\TestTTD\TestTTD.exe. Kontrollera Record process med Time Travel Debugging, Ställ in Utmatningskatalogen på en skrivbar och befintlig sökväg och klicka sedan på OK.
  3. när programmet kraschar sparar WinDbg en spårningsfil (.kör förlängning) och loggar platsen medan du laddar den.
  4. stoppa felsökaren och öppna spårningsfilens plats.

Replay

  1. Öppna WinDbg.
  2. på fliken Arkiv väljer du Inställningar från den vänstra sidofältet. Välj Felsökningsinställningar, Lägg till C:\TestTTD\src till fältet Källväg och C:\TestTTD\bin till fältet Symbol path. Klicka på OK för att spara ändringar.
  3. på fliken Arkiv väljer du öppna spårningsfil och bläddrar till spårningsfilen som skapades I steget post.

analysera

  1. när den inspelade spårfilen har laddats i WinDbg, Lägg till en brytpunkt för att stoppa och analysera applikationens tillstånd. Ladda en skriptfil från fliken Källa och klicka sedan på vänster sida av raden med önskad Brytpunkt. Hit F5 för att köra till brytpunkten.
  2. slå nu F10 för att gå över, som i en Visual Studio-felsökningssession. Klicka på steg tillbaka för att springa bakåt.

slutsatser

när felsökning produktionskod och knappast reproducerbara buggar, WinDbg och dess tidsresor Debug är ett bra verktyg för utvecklare som kan hjälpa till att spara tid och resurser genom att spela in den felaktiga ansökan bara på den drabbade miljön och ger dig möjlighet att spela det var som helst. För mer information, besök Microsoft blog, eller titta på deras demo på MSDN Channel 9: s webbplats.

Leave a Reply

Din e-postadress kommer inte publiceras.