Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
I det här avsnittet beskrivs design- och testningsöverväganden för att använda de interna felsökningsobjekten i JavaScript-tillägg.
Interna felsökningsobjekt representerar olika konstruktioner och beteenden i felsökningsmiljön. Objekten kan skickas till (eller hämtas i) JavaScript-tillägg för att ändra tillståndet för felsökningsprogrammet.
Information om JavaScript-tillägg för felsökningsobjekt finns i Interna felsökningsobjekt i JavaScript-tillägg.
Allmän information om hur du arbetar med JavaScript finns i Skript för JavaScript-felsökningsprogram.
Designöverväganden för felsökningsdatamodell
Designprinciper
Överväg följande principer för att göra felsökningstilläggen tillgängliga med information som är identifierbar, frågebar och skriptbar.
- Informationen ligger nära där den behövs. Information om en registernyckel bör till exempel visas som en del av en lokal variabel som innehåller ett registernyckelhandtag.
- Informationen är strukturerad. Information om en registernyckel visas till exempel i separata fält, till exempel nyckeltyp, nyckel-ACL, nyckelnamn och värde. Det innebär att de enskilda fälten kan nås utan att parsa text.
- Informationen är konsekvent. Information om registernyckelhandtag visas på ett så liknande sätt som möjligt som information om filhandtag.
Undvik dessa metoder som inte stöder dessa principer.
- Strukturera inte dina objekt i en enda platt "Diskbänk". Med en ordnad hierarki kan användarna söka efter den information de letar efter utan förkunskaper om vad de letar efter och stöder identifiering.
- Konvertera inte ett klassiskt dbgeng-tillägg genom att helt enkelt flytta det till modellen medan du fortfarande matar ut skärmar med rå text. Detta är inte skrivbart med andra tillägg och kan inte efterfrågas med LINQ-uttryck. Dela i stället upp data i separata, frågebara fält.
Riktlinjer för namngivning
- Fältens namnstil bör vara PascalCase. Ett undantag kan övervägas för namn som är allmänt kända i ett annat hölje, till exempel jQuery.
- Undvik att använda specialtecken som normalt inte används i en C++-identifierare. Undvik till exempel att använda namn som "Total längd" (som innehåller ett blanksteg) eller "[storlek]" (som innehåller hakparenteser). Den här konventionen möjliggör enklare förbrukning från skriptspråk där dessa tecken inte tillåts som en del av identifierarna, och möjliggör även enklare förbrukning från kommandofönstret.
Riktlinjer för organisation och hierarki
- Utöka inte den översta nivån i namnområdet för felsökaren. I stället bör du utöka en befintlig nod i felsökningsprogrammet så att informationen visas där den är mest relevant.
- Duplicera inte begrepp. Om du skapar ett datamodelltillägg som visar ytterligare information om ett koncept som redan finns i felsökningsprogrammet utökar du den befintliga informationen i stället för att försöka ersätta den med ny information. Med andra ord bör ett tillägg som visar information om en modul utöka det befintliga modulobjektet i stället för att skapa en ny lista med moduler.
- Kommandon för flytande verktyg måste vara en del av namnområdet Debugger.Utility . De bör också vara undernamnrymder på lämpligt sätt (t.ex. Debugger.Utility.Collections.FromListEntry)
Bakåtkompatibilitet och icke-bakåtkompatibla ändringar
Ett skript som publiceras ska inte bryta kompatibiliteten med andra skript som är beroende av det. Om en funktion till exempel publiceras till modellen bör den finnas kvar på samma plats och med samma parametrar när det är möjligt.
Ingen användning av externa resurser
- Tillägg får inte skapa externa processer. Externa processer kan störa felsökningsprogrammets beteende och fungerar felaktigt i olika scenarier med fjärrfelsökning (t.ex. dbgsrv-fjärranslutningar, ntsd-fjärranslutningar och "ntsd -d fjärranslutningar")
- Tillägg får inte visa något användargränssnitt. Visning av användargränssnittselement fungerar felaktigt i fjärrfelsökningsscenarier och kan bryta konsolfelsökningsscenarier.
- Tillägg får inte manipulera felsökningsmotorn eller felsökningsgränssnittet via odokumenterade metoder. Detta orsakar kompatibilitetsproblem och fungerar felaktigt på felsökningsklienter med olika användargränssnitt.
- Tillägg får endast komma åt målinformation via de dokumenterade API:erna för felsökningsprogram. Försök att komma åt information om ett mål via win32-API:er misslyckas för många fjärrscenarier, och även vissa lokala felsökningsscenarier över säkerhetsgränser.
Ingen användning av dbgeng-specifika funktioner
Skript som är avsedda att användas som tillägg får inte förlita sig på dbgeng-specifika funktioner när det är möjligt (till exempel att köra "klassiska" felsökningstillägg). Skript ska kunna användas med alla felsökningsverktyg som stöder datamodellen.
Testa tillägg för felsökningsprogram
Tillägg förväntas fungera i en mängd olika scenarier. Vissa tillägg kan vara specifika för ett scenario (till exempel ett kernel-felsökningsscenario), men de flesta tillägg bör förväntas fungera i alla scenarier eller ha metadata som anger de scenarier som stöds.
Kernelläge
- Felsökning av körande kärna
- Felsökning av kärndump
Användarläge
- Felsökning av liveanvändarläge
- Felsökning av dump i användarläge
Tänk dig dessutom dessa användningsscenarier för felsökningsprogram
- Felsökning med flera processer
- Felsökning av flera sessioner (t.ex. dump + live-användare i en enda session)
Användning av fjärrfelsökare
Testa för korrekt drift med användningsscenarier för fjärrfelsökare.
- dbgsrv-fjärranslutningar
- ntsd-fjärranslutningar
- ntsd -d fjärrkontroller
Mer information finns i Felsökning med HJÄLP av CDB och NTSD och Aktivering av en processserver.
Regressionstestning
Undersök användningen av testautomatisering som kan verifiera funktionerna i dina tillägg när nya versioner av felsökningsprogrammet släpps.
Se även
interna felsökningsobjekt i JavaScript-tillägg
Interna felsökningsobjekt i JavaScript-tillägg – Information om felsökningsobjekt.