wake-up-neo.com

Visual Studio 2015 RTM - Das Debuggen funktioniert nicht

Ich habe VS 2015 RTM (sonst nichts) installiert und kann keine Lösung debuggen, egal ob es sich um eine vorhandene oder eine brandneue handelt (erstellt mit VS 2015 und kompiliert mit .Net Framework 4.6) ) wird nur eine neue Registerkarte in VS geöffnet, die als Unterbrechungsmodus mit folgendem Text bezeichnet wird: Die Anwendung befindet sich im Unterbrechungsmodus. Ihre App hat einen Unterbrechungszustand erreicht, es wird jedoch kein Code ausgeführt, der von der ausgewählten Debug-Engine unterstützt wird (z. B. Es wird nur nativer Laufzeitcode ausgeführt. Und wenn ich das Debug -> Module Fenster überprüfe: VS2015Test.vshost.exe keine Symbole geladen (auch wenn ich auf Symbol laden klicke, funktioniert es nicht) VS2015Test.exe Symbole geladen

Außerdem wird die Ausgabe auf der Konsole nicht angezeigt (es handelt sich um eine Konsolenanwendung, die nur die folgenden Codezeilen enthält:

class Program
{
        static void Main(string[] args)
        {
            Console.WriteLine("TEST");
            Console.ReadKey();
        }
    }

Ich habe versucht, VS 2015 neu zu installieren, den Computer neu gestartet, alle Dateien in% temp%/AppData/Microsoft/Visual Studio/14 gelöscht und VS im Administratormodus gestartet, aber nichts scheint zu funktionieren.

Eine Sache, die das Debuggen zum Funktionieren bringt, ist diese Option: Extras -> Optionen -> Debuggen -> Verwalteten Kompatibilitätsmodus verwenden

^^ Aber das kann nicht die Lösung sein, um einen alten/alten Modus zu verwenden.

Übrigens: Das Debuggen in VS 2013 funktioniert einwandfrei.

Jede Hilfe wäre dankbar.

62
rene_r

In meinem Fall ist diese Lösung nützlich:

Lösung: Deaktivieren Sie die Option "Nur mein Code" in den Debugging/General-Einstellungen.

 enter image description here

Referenz: c-sharpcorner

68
mayank

Ich hatte das gleiche Problem mit VS2015. Ich habe die Einstellungen zurückgesetzt, wie vorgeschlagen, hatte aber immer noch Probleme.

Was ich tun musste, um das Problem zu beheben, war "Use Managed Compatibility Mode" und "Native Compatibility Mode". Ich bin mir nicht sicher, welche der beiden notwendig ist, aber beide prüfen, und ich bekomme nicht mehr das Problem des Unterbrechungsmodus.

Break Mode Fix - Debug Settings

42
Andy

Ich hatte kürzlich ein sehr ähnliches Problem, das sich auf Debugging-Einstellungen bezog. 

Haben Sie zuerst versucht, alle Ihre Einstellungen zurückzusetzen? Ich denke, es hängt damit zusammen, wie Sie sagen, dass es projektunabhängig ist und Sie alle Anwendungsdaten gelöscht haben.

Extras-> Import- und Exporteinstellungen Wizard -> Alle Einstellungen zurücksetzen

Machen Sie sich keine Sorgen, es gibt Ihnen die Möglichkeit, die aktuellen Einstellungen zu speichern. 

Zweitens, wenn dies fehlschlägt, würde ich vorschlagen, das Ereignisprotokoll anzusehen. 

Wenn Sie den Unterbrechungsmodus aufrufen, wird davon ausgegangen, dass die DE (Debug-Engine) ein synchronisiertes Stoppereignis wie IDebugExceptionEvent2 an Visual Studio sendet. Ich möchte im Ereignisprotokoll nach Ausnahmen wie Fehlern beim Laden referenzierter Assemblys (wie .NET-Laufzeit usw.) oder Zugriffsbeschränkungen für die Umgebung suchen. 

Etwas sagt dem Debugger, dass er die laufende Anwendung anhalten soll. 

15
garyamorris

Ich dachte, ich würde das hier posten, falls es jemandem hilft. Ich habe ein sauberes Win 10 und Visual Studio 2015 installiert, versucht, eine vorhandene Lösung zu debuggen, und hatte Probleme. Befolgen Sie einige Ratschläge, die hier und an anderen Orten aufgeführt sind, aber keiner hat funktioniert.

Wie ich das Debuggen normal arbeiten konnte, war, die Lösungskonfiguration direkt unter den Menüs zu ändern. Ich hatte es zuvor auf Release-Modus gesetzt, dies in Debug geändert und dann gereinigt/neu kompiliert und hey, das Debuggen funktionierte normal. Siehe das Bild für Informationen:

 enter image description here

14
KDee

Meine Lösung hat plötzlich aufgehört zu arbeiten in Debug . Ich habe während des Debugging eine Nachricht erhalten . I received a message during debug

[Fenstertitel] Microsoft Visual Studio [Hauptanleitung] Sie debuggen einen Release-Build von NettoProWin.exe. Die Verwendung von Nur My Code with Release-Builds mit Compiler-Optimierungen führt zu einer Beeinträchtigung der Debugging-Erfahrung (z. B. werden Haltepunkte nicht getroffen) . [Debuggen beenden] [Nur meinen Code deaktivieren und fortfahren] [Debuggen fortsetzen] [Debuggen fortsetzen (nicht mehr fragen)]

Ich entschied mich für das Debuggen, aber es hat immer noch nicht funktioniert.

Die Lösung war einfach. In den Projekteigenschaften -> im Build-Bereich -> remote ist die Überprüfung "Optimiz-Code"erforderlich enter image description here

6
Roberto Gata

Überprüfen Sie den "Code-Typ", bevor Sie einen Prozess anhängen. Zum Beispiel musste ich von CoreCLR zu v4 wechseln. *

 Select Code Type

3
Lee Gunn

Beim Versuch, Debugger zu verwenden, hatte ich ein ähnliches Problem. Launch zum Debuggen einer Webanwendung: Das Fenster "JIT-Debugger-Auswahl" wurde nie angezeigt. Ich wusste, dass es kein Problem mit dem VS-Debugging-Mechanismus selbst war, da er mit einer Konsolen-App problemlos ausgelöst wurde.

Schließlich erwähnte ein Kollege eine "globale Debugger-Registrierungseinstellung", die eine Glühbirne auslöste. 

Ich habe vor einigen Monaten das DebugDiag-Programm von Microsoft verwendet, um den Absturz von IIS zu beheben, und ich hatte eine Regel registriert, um IIS Crash-Dumps zu erfassen, die den Debug-Diagnosedienst (im Rückblick) offensichtlich als Debugger für w3wp ( IIS-Arbeitsprozess).

Durch das Entfernen der Regel in DebugDiag oder das Stoppen des Debug-Diagnosediensts ("C:\Programme\DebugDiag\DbgSvc.exe") wurde das JIT-Debugging von Visual Studio erneut aktiviert.

Hoffe das hilft jemandem.

1
Alex Beynenson

Ich habe den avast-Dateisystemschutz deaktiviert und dann funktionierte alles wieder normal. avast-Einstellrad = aktive Schutzeinrichtung - obere Taste aus.

Dasselbe ist erforderlich, um Projekte zu veröffentlichen. Ein echter Alptraum 

1
Sten Björsell

Uhg. Ich habe mich am Ende dieser Seite angeschlagen, also habe ich mein Projekt auseinandergerissen. Ich habe eine Lösung für mein spezielles Problem gefunden.

Mein Problem: Ich konnte den Bruchpunkt in einem Threadprozess nicht erreichen. Nichts Besonderes, ich fange gerade einen neuen Thread in einer Konsolen-App an und der Debugger stoppte nicht an den Haltepunkten. Ich habe bemerkt, dass der Thread erstellt wurde, aber er wurde in externen Aufrufen von .Net Framework und speziell im ThreadStart_Context aufgehängt. Das erklärt, warum meine Haltepunkte nie getroffen wurden, weil das .Net Framework aufgehängt ist.

Das Problem: Ich habe festgestellt, dass ich das Problem lösen kann, indem ich meinen Startcode ändere. Aus irgendeinem Grund hatte ich eine program.cs-Datei, die Main () enthielt und sich innerhalb der Programmklasse befand, wie Sie es für eine Konsolen-App erwarten würden. In Main () habe ich eine andere Klasse über diesen Code instanziiert.

new SecondClass();

Normalerweise funktioniert das einwandfrei und ich habe eine Reihe anderer Projekte mit Threaded-Aufrufen, bei denen es gut funktioniert (na ja, ich habe sie einige Zeit nicht debuggt, also kam vielleicht ein Service Pack dazu und verursacht diese Regression). 

Die Lösung: Main () in meine SecondClass verschieben und anstelle des SecondClass-Konstruktors über 'new SecondClass ()' den SecondClass-Konstruktor als statische Standardmethode aktualisieren und dann von Main aus aufrufen. Nach diesen Änderungen kann ich den Thread erneut debuggen.

Hoffe das hilft.

1
GrayDwarf

In meinem Fall, 

Ich habe in Debug Configuration Manager die Plattform von x86 in x64 geändert. Es hat für mich funktioniert.

1
Bhagwant

Nach der Installation von vs 2017 kam es beim Debuggen der Lösung zu einem Fehler wie "Webkit funktioniert nicht mehr ordnungsgemäß; Visual Studio kann Ihre App nicht weiter debuggen.", dadurch kann das Debugging nicht fortgesetzt werden. Um dieses Problem zu beheben, gehen Sie zu Tools-> Optionen-> Debugging-> Allgemein und deaktivieren Sie das JavaScript-Debugging für asp.net.

1
M Sagar

Ich habe mein Platform Target von "Any CPU" in "x64" geändert.

Einstellung verfügbar unter: Projekteigenschaften -> Erstellen -> Allgemein: "Plattformziel"

Ich benutze VS 2015.

0
murphy1310

In meinem Fall habe ich im Ausgabefenster einen Hinweis gefunden, dass die Ausnahme, die den Debugger gestoppt hat, eine ContextSwitchDeadlock-Ausnahme war, die standardmäßig in den Ausnahmeeinstellungen überprüft wird. Diese Ausnahme tritt normalerweise in Konsolenanwendungen nach 60 Sekunden auf. Ich habe gerade die Ausnahme deaktiviert und alles hat gut funktioniert.

 enter image description here

0
Fritz

 Just change your Configuration from Release to Debug

aus dem Projektmappen-Explorer -> Web -> Eigenschaften

wählen Sie die Registerkarte "Erstellen" -> Kombinationsfeld "Konfiguration":

Ändern Sie einfach Ihre Konfiguration von "Release" in "Active (Debug)".

0
HoangYell
  1. Stoppen Sie das Debuggen.
  2. Bearbeiten Sie die Datei csproj.user
  3. Suchabschnitt schrieb unten:

    <SilverlightDebugging> True </ SilverlightDebugging>

  4. Wert in "False" ändern
  5. Laden Sie Ihr Projekt in Visual Studio und laden Sie es erneut.
  6. Manchmal musste Visual Studio geschlossen werden.
0

Ich habe festgestellt, dass ich zu den Projekteinstellungen -> Web gehen musste, und das Kontrollkästchen Enable Edit and Continue aktivieren. Ich kann nicht sagen, warum es anfangs unkontrolliert war, aber das löste es für mich .  enter image description here

0
arame3333

Wir hatten dieses Problem, nachdem wir alle anderen Optionen ausprobiert hatten, z. B. das Löschen des .vs-Ordners, das Umbenennen des IISExpress-Ordnernamens, das Aktualisieren verschiedener Einstellungen für Eigenschaften usw. Es hat nicht funktioniert. Was jedoch funktioniert hat, war die Deinstallation von IISExpress 10.0 und die Neuinstallation von IISExpress sowie das Aktivieren aller mit IIS zusammenhängenden Funktionen von Windows-Funktionen. Hoffe das hilft jemandem. 

0
user6723403

Ich hatte das gleiche Problem. In meinem Fall wurde die DLL, die ich debuggen wollte, im GAC installiert. Wenn Ihr Debugging-Haltepunkt einen Treffer hat, wenn Sie kein Objekt in der Ziel-Assembly referenzieren, nicht aber beim Referenzieren der Assembly, ist dies möglicherweise der Fall für Sie.

0
user8227756

Ich hatte ähnliche Probleme mit meiner svc-Anwendung, die auf Visual Studio 2015 ausgeführt wurde. Die Lösung bestand darin, die Lösungsplattform von "Any CPU" in "x86" zu ändern. Wenn Sie die x86-Option nicht sehen können, klicken Sie auf "Configuration Manager" und gehen Sie zu Ihrem Zielprojekt und Ändern der Plattform, müssen Sie das Dropdown-Menü auswählen und auf "Neu" klicken. Klicken Sie im Popup-Menü auf die Dropdown-Liste unter "Neue Plattform" und wählen Sie x86 aus. Speichern Sie Ihre Änderungen und erstellen Sie sie neu (siehe Anhang enter image description here )

0
Ronny

In meinem Fall lag es an dem Projekt, dass Zielplattformen unterschiedlich waren.

Betrachten: ProjectA (Eintrag) -> ProjectB

Die ProjectA-Plattform in den Eigenschaften wurde auf x64 ..__ festgelegt. Die ProjectB-Plattform war 'AnyCPU'.

Nachdem ProjectBs Zielplattform auf x64 gesetzt wurde, wurde dieses Problem behoben.

 enter image description here

Hinweis: Es ist nur so, dass die Zielplattform synchron sein muss, sei es x64 oder 'Jede CPU'

0
Koder101

Ich hatte dieses Problem und keiner der (unzähligen) Beiträge hier hat geholfen. Die meisten Leute weisen auf Einstellungen oder Optionen hin, den Debug-Modus einschalten usw. All dies hatte ich bereits (ich wusste, dass es nicht so war, da dies gestern gut funktionierte).

Für mich stellte sich heraus, dass es sich um ein Referenzierungsproblem handelte, dass eine Kombination von enthaltenen DLLs daran schuld war. Ich kann nicht genau sagen, was das Problem war, aber ich habe ein paar Klassen, die Basisklassen aus einem anderen Projekt erweitert haben, eine implementierte Schnittstelle, die sich selbst von einer anderen Schnittstelle aus erstreckt, usw.

Der Härtetest bestand darin, eine neue Klasse (in meinem Fall einen Komponententest) innerhalb desselben Projekts zu erstellen, in der auch das Debugging fehlgeschlagen ist. Anschließend wurde eine leere Methode erstellt und ein Haltepunkt festgelegt. Das hat funktioniert, was die Tatsache bestätigt, dass meine Einstellungen/Optionen/etc gut waren. Ich kopierte dann den Rumpf der Methode, die nicht debuggen konnte, und die neue Methode fängt an, auch zu scheitern. 

Am Ende entfernte ich alle Referenzen und kommentierte alle Zeilen in meiner Methode aus. Ich fügte sie nacheinander hinzu und überprüfte bei jedem Schritt Debug, bis ich den Täter gefunden hatte. Ich hatte offensichtlich irgendwo einen Schurkenreferenz ...

0
Detail

Ein Freund hatte das gleiche Problem, er konnte zwar nicht in VS2015 debuggen, war aber in VS2013 in Ordnung. (unser Projekt ist in .Net v4.0)

Wir haben festgestellt, dass die Option "Code Type" in Debug/Attach to Process auf "Managed (v3.5, v3.0, v2.0)" statt "Managed (v4.5, v4.0)" gesetzt wurde ) "

0
whaly