Öka risken för att ett prestandaproblem åtgärdas
Verktyget "Report a problem" används ofta av Visual Studio-användare för att rapportera en rad problem. Visual Studio-teamet upptäcker krasch- och långsamhetstrender i användarfeedback och åtgärdar problem som påverkar en stor mängd användare. Ju mer åtgärdsbar en specifik feedbackbegäran är, desto mer sannolikt kommer den att diagnostiseras och lösas snabbt av produktteamet. Det här dokumentet beskriver metodtipsen vid rapportering av krasch- eller långsamhetsproblem för att göra dem mer användbara.
Allmänna metodtips
Visual Studio är en stor, komplex plattform som stöder en mängd olika språk, projekttyper, plattformar med mera. Hur det fungerar är en funktion av vilka komponenter som installeras och är aktiva i en session, tilläggen installerade, Visual Studio-inställningarna, datorkonfigurationen och slutligen formen på den kod som redigeras. Med tanke på antalet variabler är det svårt att avgöra om problemrapporten från en användare har samma underliggande problem som en problemrapport från en annan användare, även om det synliga symptomet är detsamma. Med tanke på detta är här några metodtips för att säkerställa att din specifika problemrapport har högre sannolikhet att diagnostiseras.
Ange en så specifik rubrik som möjligt
Leta efter distinkta signaturer för problemet som rapporteras och inkludera så mycket som möjligt i rubriken. Om rubriken är beskrivande är det mindre troligt att användare med orelaterade problem (men samma ytliga symptom) kommer att rösta eller kommentera din biljett, vilket gör diagnos av ditt problem svårare.
När du är osäker loggar du en ny problemrapport
Många problem kanske inte har någon distinkt signatur eller några steg för att återskapa dem. I sådana fall är en ny rapport bättre än en uppröstning eller en kommentar till en annan rapport, som rapporterar ett liknande utåtsett symptom. Beroende på typ av rapport kan du inkludera ytterligare diagnostikfiler i rapporten enligt beskrivningen senare i det här dokumentet.
Problemspecifika metodtips
Nedan beskrivs problem som är svåra att diagnostisera utan bra diagnostikfiler. När du har identifierat det fall som bäst beskriver problemet följer du de feedbacksteg som är specifika för det fallet.
Kraschar: En krasch inträffar när processen (Visual Studio) avslutas oväntat.
Svarar inte: VS svarar inte under en längre tid.
problem med långsamhet: En specifik åtgärd i VS är långsammare än förväntat
Hög PROCESSORANVÄNDNING: Längre perioder med oväntat hög CPU-användning
Ut-Of-Process Problem: Ett problem som orsakas av en Visual Studio-satellitprocess
Kraschar
En krasch inträffar när processen (Visual Studio) avslutas oväntat.
Direkt återupprepbara krascher
Direkt reproducerbara krascher är fall som har följande egenskaper:
Kan observeras genom att följa en känd uppsättning steg
Kan observeras på flera datorer (om tillgängligt)
Kan reproduceras i exempelkod eller ett projekt som kan länkas till eller tillhandahållas som en del av feedbacken (om stegen omfattar att öppna ett projekt eller dokument)
För dessa problem följer du stegen i "Rapportera ett problem" och se till att inkludera:
Stegen för att återskapa problemet
Ett fristående repro-projekt enligt beskrivningen ovan. Om fristående repro inte är möjligt ska du inkludera:
Språket för de öppna projekten (C#, C++, osv.)
Typ av projekt (konsolprogram, ASP.NET osv.)
Not
Mest värdefulla feedback: I det här fallet är den mest värdefulla feedbacken en uppsättning steg för att återskapa problemet tillsammans med exempel på källkod.
Okända krascher
Om du inte är säker på vad som orsakar krascherna eller om de verkar slumpmässiga kan du samla in dumpar lokalt varje gång Visual Studio kraschar och koppla dem till separata feedbackobjekt. Om du vill spara dumpar lokalt när Visual Studio kraschar kör du följande kommandon i ett administratörskommandofönster:
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe" /v DumpType /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe" /v DumpCount /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe" /v DumpFolder /t REG_SZ /d "C:\CrashDumps"
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService32.exe" /v DumpType /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService32.exe" /v DumpCount /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService32.exe" /v DumpFolder /t REG_SZ /d "C:\CrashDumps"
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService.exe" /v DumpType /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService.exe" /v DumpCount /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService.exe" /v DumpFolder /t REG_SZ /d "C:\CrashDumps"
Anpassa dumpantalet och dumpmappen efter behov. Mer information om de här inställningarna finns här.
Not
Dumpar som samlas in med Hjälp av Aktivitetshanteraren kommer sannolikt att ha fel bitighet, vilket gör dem mindre användbara. Proceduren som beskrivs ovan är det föredragna sättet att generera en heapdump. Om du vill använda Aktivitetshanteraren stänger du den som körs för närvarande, startar 32-bitars Aktivitetshanteraren (%windir%\syswow64\taskmgr.exe) och samlar in en heapdump därifrån.
Notis
Varje dumpfil som skapas med den här metoden är upp till 4 GB. Se till att ange DumpFolder till en plats med tillräckligt med diskutrymme eller justera DumpCount på rätt sätt.
Varje gång Visual Studio kraschar skapas en dumpfil devenv.exe. [number].dmp fil på den konfigurerade platsen.
Använd sedan Visual Studios funktion "Rapportera ett problem". Det gör att du kan bifoga lämplig dump.
Leta upp dumpfilen för kraschen du rapporterar (leta efter en fil med rätt skapandetid)
Om möjligt zippar du filen (*.zip) för att minska dess storlek innan du skickar feedback
Följ stegen i "Rapportera ett problem" och bifoga heapdumpen till ett nytt feedbackobjekt.
Not
Mest värdefulla återkopplingen: För det här fallet är den värdefullaste återkopplingen den heap-dump som togs vid tidpunkten för kraschen.
Svarar inte
VS svarar inte under en längre tid.
direkt reproducerbar Oresponsivitet
Som beskrivs i motsvarande avsnitt om krascher, för problem som enkelt kan återskapas, visas på flera datorer och kan visas i ett litet exempel, är de mest värdefulla feedbackrapporterna sådana som innehåller steg för att återskapa problemet och inkludera exempelkällkod som visar problemet.
Okänd Oresponsivitet
Om ett icke-svar uppstår på ett oförutsägbart sätt, starta vid nästa förekomst en ny instans av Visual Studio och rapportera ett problem från den instansen. På skärmen "Spela in" måste du välja den Visual Studio-session som inte svarar. (Mer information om hur du registrerar åtgärder som vi kan följa för att återskapa problemet finns i Steg 8 på Rapportera ett problem sidan.)
Om Visual Studio-instansen som inte svarar startades i administratörsläge måste även den andra instansen startas i administratörsläge.
Not
Mest värdefulla feedback: För det här fallet är den mest värdefulla feedbacken den heap dump som fångades vid tidpunkten för när systemet var icke-svarande.
Problem med långsamhet och hög CPU
Det som gör ett problem med långsam eller hög CPU-användning mest användbar är en prestandaspårning som registreras medan den långsamma åtgärden eller den höga CPU-händelsen pågår.
Anteckning
När det är möjligt isolerar du varje scenario i en separat, specifik feedbackrapport. Om det till exempel är långsamt att skriva och navigera följer du stegen nedan en gång per problem. Detta hjälper produktteamet att isolera orsaken till specifika problem.
Följ dessa steg för att få bästa resultat när det gäller att samla in prestanda:
Om den inte redan körs har du en kopia av Visual Studio öppen där du återskapar problemet
Ha allt konfigurerat för att återskapa problemet. Om du till exempel behöver ett visst projekt för att läsas in med en specifik fil öppnad måste du se till att båda dessa steg är slutförda innan du fortsätter.
Om du inte rapporterar ett problem som är specifikt för inläsning av en lösning kan du försöka vänta 5–10 minuter (eller mer, beroende på lösningsstorleken) efter att du har öppnat lösningen innan du registrerar prestandaspårningen. Lösningens inläsningsprocess genererar en stor mängd data, så att vänta några minuter hjälper oss att fokusera på det specifika problem som du rapporterar.
Starta en andra kopia av Visual Studio utan att någon lösning är öppen
I den nya kopian av Visual Studio öppnar du verktyget Report a Problem
Följ stegen i Rapportera ett problem tills du når steget "Ange en spårnings- och heapdump (valfritt)."
Välj att spela in den första kopian av Visual Studio (den som stöter på prestandaproblem) och starta inspelningen.
Programmet Steps Recorder visas och börjar spela in.
Under inspelningen, utför den problematiska åtgärden i den första kopian av Visual Studio. Det är svårt för oss att korrigera specifika prestandaproblem om de inte visas inom den registrerade tiden.
Om åtgärden är kortare än 30 sekunder och enkelt kan upprepas upprepar du åtgärden för att ytterligare demonstrera problemet.
I de flesta fall räcker det med en spårning på 60 sekunder för att demonstrera problemen, särskilt om den problematiska åtgärden varade (eller upprepades) i mer än 30 sekunder. Varaktigheten kan justeras efter behov för att fånga in det beteende som du vill ha åtgärdat.
Klicka på "Stoppa inspelning" i Steps Recorder så snart den långsamma åtgärden eller höga CPU-händelsen som du vill rapportera är klar. Det kan ta några minuter att bearbeta prestandaspårningen.
När du är klar kommer det att finnas flera bifogade filer till din feedback. Bifoga eventuella ytterligare filer som kan hjälpa till att återskapa problemet (ett exempelprojekt, skärmbilder, videor osv.).
Skicka feedbacken.
När du spelar in en prestandasporing kan du omedelbart stoppa inspelningen om den långsamma åtgärden eller den höga CPU-belastningen som du rapporterar upphör. Om för mycket information samlas in skrivs den äldsta informationen över. Om spårningen inte stoppas snart (inom några sekunder) efter den intressanta åtgärden skrivs användbara spårningsdata över.
Koppla inte prestandaspårningar direkt till befintliga feedbackobjekt på utvecklarcommunitywebbplatsen. Att begära/tillhandahålla ytterligare information är ett arbetsflöde som stöds i Visual Studio inbyggda rapportverktyg för problem. Om en prestandaspårning krävs för att lösa ett tidigare feedbackobjekt ställer vi in tillståndet för feedbackobjektet på "Behöver mer information", vilket kan besvaras på samma sätt som när ett nytt problem rapporteras. Detaljerade instruktioner finns i avsnittet "Behöver mer information" i dokumentet rapportera ett problemverktyg.
Anmärkning
Mest värdefulla feedback: För nästan all långsamhet och hög CPU-användning är den mest värdefulla feedbacken en övergripande beskrivning av vad du försökte göra, tillsammans med prestandaspårning (*.etl.zip) som fångar beteendet under den tiden.
Avancerade prestandaspårningar
Funktionerna för spårningsinsamling i verktyget Report-a-problem räcker för de flesta scenarier. Men det finns tillfällen då mer kontroll över spårningsinsamling behövs (till exempel spårning med större buffertstorlek), i vilket fall PerfView är ett bra verktyg att använda. Steg för att registrera prestandaspårning manuellt med verktyget PerfView finns på sidan Inspelning av prestandaspårningar med PerfView.
Problem medOf-Process
Not
Från och med Visual Studio 2019 version 16.3 kopplas out-of-process-loggar automatiskt till feedback som skickas med verktyget Rapportera ett problem. Men om problemet är direkt reproducerbart kan följande steg fortfarande bidra till att lägga till ytterligare information för att bättre diagnostisera problemet.
Det finns ett antal satellitprocesser som körs parallellt med Visual Studio och som tillhandahåller olika funktioner utanför den huvudsakliga Visual Studio-processen. Om ett fel uppstår i någon av dessa satellitprocesser visas det vanligtvis på Visual Studio-sidan som en "StreamJsonRpc.RemoteInvocationException" eller en "StreamJsonRpc.ConnectionLostException".
Det som gör de här typerna av problem mest användbara är att tillhandahålla ytterligare loggar som kan samlas in genom att följa dessa steg:
Om det här är ett direkt reproducerbart problem börjar du med att ta bort mappen %temp%/servicehub/logs. Om du inte kan återskapa det här problemet bör du behålla den här mappen intakt och ignorera följande punkter:
- Ange den globala miljövariabeln ServiceHubTraceLevel till Alla
- Återskapa problemet.
Ladda ned logginsamlingsverktyget för Microsoft Visual Studio och .NET Framework här.
Kör verktyget. Detta matar ut en zip-fil till %temp%/vslogs.zip. Bifoga filen i din feedback.