Felsöka brytpunkter i Visual Studio-felsökningsprogrammet

Artikel
11/14/2023

Gäller för: Visual Studio

Brytpunktsvarningar

Vid felsökning har en brytpunkt två möjliga visuella tillstånd:

En heldragen röd cirkel, om felsökaren har angett en brytpunkt i målprocessen.
En ihålig cirkel (vit fylld), antingen inaktiveras brytpunkten eller så uppstod en varning när brytpunkten skulle anges.

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 fönstret Moduler (Felsöka>Windows-moduler>) när du felsöker och kontrollera om modulen har lästs in.

Om modulen har lästs in kontrollerar du kolumnen Symbolstatus för att se om symbolerna har lästs in.
- Om symbolerna inte läses in kontrollerar du symbolstatusen för att diagnostisera problemet. I snabbmenyn i en modul i fönstret Moduler väljer du Symbolinläsningsinformation... för att se var felsökaren tittade för att försöka läsa in symboler. Mer information om hur du läser 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 avskalade PDF-filer med hjälp av länkalternativet /PDBSTRIPPED . Avskalade PDF-filer innehåller inte källfilsinformation. 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 har lästs 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 tror att projektet redan är uppdaterat även om det inte är det, kan du tvinga projektsystemet att återskapa det. Å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ökning, 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 den ursprungliga versionen . Se till att du kan använda det här alternativet igen när du är klar med felsökningen.

Brytpunkten har angetts (ingen varning), men träffade inte

Det här avsnittet innehåller information om hur du felsöker problem när felsökaren inte visar några varningar – brytpunkten är en helröd cirkel medan den aktivt felsöker, men brytpunkten påverkas 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.
För att ansluta 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+). Undersök genom att markera alternativet Bifoga till i dialogrutan Bifoga till process och välj 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 trycka på 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 .

Share via