Felsöka brytpunkter i Visual Studio-felsökningsprogrammet
Gäller för: Visual Studio
Brytpunktsvarningar
Vid felsökning har en brytpunkt två möjliga visuella tillstånd:
- En fast röd cirkel om felsökningsprogrammet har angett en brytpunkt i målprocessen.
- En ihålig cirkel (mörkgrå eller vit fylld, beroende på ditt tema), om brytpunkten är inaktiverad eller om en varning inträffar när brytpunkten försöker ställas in.
För att fastställa skillnaden hovra över brytpunkten och se om det finns en varning. I följande två avsnitt beskrivs tydliga varningar och hur du åtgärdar dem.
"Inga symboler har lästs in för det här dokumentet"
Gå till Felsöka>Windows-moduler> vid felsökning och kontrollera om modulen har lästs in.
- Om modulen har lästs in kontrollerar du kolumnen Symbolstatus för att se om symboler har lästs in.
Om symbolerna inte läses in kontrollerar du symbolstatusen för att diagnostisera problemet:
I fönstret Moduler högerklickar du på modulen som symbolerna inte har lästs in för och väljer Symbolinläsningsinformation....
Mer information om att läsa in symboler finns i Ange symbol (.pdb) och Källfiler.
Om symboler läses in innehåller pdb inte information om dina källfiler. Några möjliga orsaker är:
- Om källfilerna nyligen har lagts till kontrollerar du att en uppdaterad version av modulen läses in.
- Det går att skapa borttagna PDF-filer med hjälp av alternativet /PDBSTRIPPED-länkare . Borttagna PDF-filer innehåller inte källfilinformation. Bekräfta att du arbetar med en fullständig PDB och inte en avskalad PDB.
- PDB-filen är delvis skadad. Ta bort filen och kör en ren version av modulen för att försöka lösa problemet.
- Om modulen inte läses in kontrollerar du följande för att hitta orsaken:
- Bekräfta att du felsöker rätt process.
- Kontrollera att du felsöker rätt kod. Du kan ta reda på vilken typ av kod felsökaren är konfigurerad för att felsöka i fönstret Processer (Felsöka>Windows-processer).> Om du till exempel försöker felsöka C#-kod kontrollerar du att felsökningsprogrammet har konfigurerats för lämplig typ och version av .NET (till exempel Hanterad (v4*) jämfört med Hanterad (v2*/v3*) jämfört med Hanterad (CoreCLR)).
"… den aktuella källkoden skiljer sig från den inbyggda versionen..."
Om en källfil har ändrats och källan inte längre matchar den kod som du felsöker, anger felsökaren inte brytpunkter i koden som standard. Normalt inträffar det här problemet när en källfil ändras, men källkoden återskapades inte. Åtgärda problemet genom att återskapa projektet. Om byggsystemet anser att projektet redan är uppdaterat även om det inte är det, kan du tvinga projektsystemet att återskapas. Återskapa projektet antingen genom att spara källfilen igen eller genom att rensa byggutdata innan du skapar.
I sällsynta fall kanske du vill felsöka utan att ha matchande källkod. Felsökning utan matchande källkod kan leda till en förvirrande felsökningsupplevelse, så se till att du vill fortsätta.
Följ något av alternativen för att inaktivera dessa säkerhetskontroller:
- Om du vill ändra en enda brytpunkt hovrar du över brytpunktsikonen i redigeraren och väljer inställningsikonen (kugghjulet). Ett granskningsfönster läggs till i redigeraren. Överst i granskningsfönstret finns en hyperlänk som anger brytpunktens plats. Välj hyperlänken för att tillåta ändring av brytpunktsplatsen och markera Tillåt att källkoden skiljer sig från originalet.
- Om du vill ändra den här inställningen för alla brytpunkter går du till Felsökningsalternativ>och Inställningar. På sidan Felsökning/Allmänt avmarkerar du alternativet Kräv källfiler som exakt matchar det ursprungliga versionsalternativet . Se till att återaktivera det här alternativet när du är klar med felsökningen.
Brytpunkten har angetts (ingen varning), men träffade inte
Det här avsnittet innehåller information för att felsöka problem när felsökaren inte visar några varningar – brytpunkten är en röd cirkel vid aktiv felsökning, men brytpunkten slås inte.
Här följer några saker att kontrollera:
- Om koden körs i mer än en process eller flera datorer kontrollerar du att du felsöker rätt process eller dator.
- Bekräfta att koden körs. Om du vill testa att koden körs lägger du till ett anrop till
System.Diagnostics.Debugger.Break
(C#/VB) eller__debugbreak
(C++) till den kodrad där du försöker ange brytpunkten och sedan återskapa projektet. - Om du felsöker optimerad kod kontrollerar du att funktionen där brytpunkten har angetts inte är inlindad i en annan funktion. Testet
Debugger.Break
som beskrivs i föregående kontroll kan också fungera för att testa det här problemet. - Om du vill koppla till processscenarier kontrollerar du att du felsöker rätt typ av kod (till exempel skriptkod jämfört med .NET Framework jämfört med .NET 5+). Om du vill undersöka markerar du alternativet Anslut till i dialogrutan Anslut till process och väljer Välj om det behövs för att ändra kodtypen.
Jag har tagit bort en brytpunkt, men jag fortsätter att trycka på den när jag börjar felsöka igen
Om du har tagit bort en brytpunkt under felsökningen kan du träffa brytpunkten igen nästa gång du börjar felsöka. Om du vill sluta träffa den här brytpunkten kontrollerar du att alla instanser av brytpunkten har tagits bort från fönstret Brytpunkter.