VS2019 Debuggen funktioniert nicht mehr

  • VB.NET
  • .NET (FX) 1.0–2.0

Es gibt 23 Antworten in diesem Thema. Der letzte Beitrag () ist von RiLo.

    VS2019 Debuggen funktioniert nicht mehr

    Hallo zusammen,

    ich habe eine Projektmappe mit 12 Projekten darin. Egal welches der 12 Projekte ich versuche zu debuggen kommt immer wieder die Meldung in der Ausgabe "Das Programm xyz.exe wurde mit Code -2146233082 (0x80131506) beendet."
    Vor ca. einem halben Jahr hat das Debuggen mit dieser Projektmappe noch funktioniert.
    Wenn ich eine andere Mappe öffne, funktioniert das Debuggen problemlos.

    Vielleicht noch einige Infos zu den Projekten in der Mappe:
    - alle Projekte für x86
    - alle Projekte Zielframework NET Framework 2.0 (ja, ist schon was älter, lief aber bisher problemlos)
    - es werden keine weiteren DLLs eingebunden (außer diese Standard System-Geschichten)
    - alle Anwendungen greifen per DCOM auf OPC-Server zu (Kommunikation mit SPSen, speicherprogrammierbare Steuerungen, Industrie)

    Meine bisherigen Lösungsansätze (teils auch mit Hilfe des Internets) waren:
    - Rücknahme aller zuletzt getroffenen Änderungen im Quellcode
    - Deinstallation und erneute Installation des NET-Frameworks
    - Verwenden eines älteren Standes der Projektmappe
    - Updates Win10 und Visual Studio
    - Deinstallation und erneute Installation Visual Studio

    Wobei ich noch sagen möchte, dass die anderen, funktionierenden Projektmappen auch über DCOM auf OPC-Server zugreifen. Ich denke also nicht, dass es an den DCOM-Einstellungen meines Systems liegt.

    Hatte jemand schon einmal ein ähnliches Problem und eventuell noch einen heißen Tipp für mich? So langsam bin ich mit meinen Kenntnissen am Ende.

    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    @RodFromGermany

    Die Seite hatte ich auch schon gefunden. Allerdings ist mir der Umgang mit WinDbg nicht vertraut. Die erste Frage wäre schon: Lade ich das VisualStudio als exe in WinDbg oder hänge ich mich nur an den Prozess für das Time Traveling?

    Was vielleicht noch zu sagen wäre: Wenn ich meine "fehlerhaften" Anwendungen kompiliere und auf den Zielsystemen ausführe, funktioniert alles wunderbar.

    Vielleicht eine Sicherheitskopie des Projektordners erstellen und mit einem anderen Zielframework probieren (irgendetwas ab .NET-Framework 3.5), sofern das alles dann natürlich sinnvoll/erwünscht, kompatibel und noch lauffähig ist – nach einer Kopieerstellung kann man sich das Probieren aber erlauben. Ich selbst habe seit 2019 mit dem damals neuen VS2019 gearbeitet und hatte eigentlich keine größeren Probleme mit dem Debugger – ich benutze diesen aber in der Regel nur, um Dinge wie dynamischen Speicherbedarf, Anzahl der Objekte usw. zu überprüfen/überwachen, zum Debuggen für Infoausgabe habe ich meine eigene Vorlage im Programm implementiert, die dann ermöglicht, das Programm in Echtzeit, optimiert und ohne Verzögerungen laufen zu lassen. In VS2019 hatte ich manchmal Probleme mit dem Designer, der anscheinend durch meine Art die Dinge im Code zu bezeichnen durcheinander kam und einige Teile des Codes einfach sporadisch kurzerhand entfernte – habe dann regelmäßig Kopie des Projektordners erstellen müssen, um in so einem Fall die 10-20 Zeilen Code, die ich lokalisieren musste, schneller von Hand rekonstruieren zu können; wohlgemerkt in der Designer-Datei, wo man eigentlich nichts zu suchen hat, aber genau dort hat er – angeregt durch meine Bezeichnungen – seinen Unfug getrieben. Ende 2022 habe ich mich dann entschlossen, parallel dazu VS2022 zu installieren, um soweit es geht, nicht „rückständig” in der Hinsicht zu sein – das benutze ich jetzt; das Migrieren/Laden des Projekts (hier auch vorher immer eine vollständige Kopie erstellen) aus VS2019 ist eigentlich ohne Probleme verlaufen – in VS2022 scheint aber (meiner Meinung nach) ein kleiner Bug in der Ressourcenverwaltung für Bilder zu existieren – zumindest bei Erstellung einer (neuen) WPF-Anwendung und nicht WinForms mit .NET-Framework, ist aber jetzt nicht so relevant, da nicht Gegenstand des Threads hier. VS2019 und VS2022 können jedenfalls in Windows 10 nebeneinander existieren und separat agieren – funktioniert auch mit Unity (Spieleerstellung), das Häkchen muss aber für Unity bei der Installation oder deren jederzeit anschließender Änderung angeklickt sein, sonst hat man ein Problem mit IntelliSense – das „normale” Schreiben, wie man es mit der automatischen Vervollständigung gewohnt ist, kann man dann glatt vergessen. Unity-IDE hat – neben ihren Vorteilen – auch ihre Nachteile – ist alles ziemlich umfangreich und überladen, wenn man etwas Kleineres und Flottes erstellen möchte, in WPF habe ich dieses „Problem” nicht, muss mich dann aber in der 2D-Grafik um alles selbst kümmern – ist nichts für „schwache Nerven”, würde ich mal so salopp sagen.
    Das gleichzeitige Erscheinen von Dummheit und Unmündigkeit nach Immanuel Kant ist eines der schlimmsten Dinge, die einem Homo sapiens in geistiger Hinsicht widerfahren können, hat manchmal aber auch durchaus seine Vorteile.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Gregor Jasinski“ ()

    Hallo zusammen,

    @Gregor Jasinski: Ich habe die Projektmappe jetzt mal auf Framework 3.5 hochgezogen, es hat sich allerdings am ursprünglichen Problem nichts geändert.

    @RodFromGermany: Ich habe mich etwas mit WinDbg beschäftigt und eine der problematischen, aber kompilierten Anwendungen darin gestartet.

    Hier zunächst die ersten Ausgabe des Debuggers:

    Quellcode

    1. Microsoft (R) Windows Debugger Version 10.0.25200.1003 X86
    2. Copyright (c) Microsoft Corporation. All rights reserved.
    4. CommandLine: C:\Projektpfad\xyz.exe
    6. ************* Path validation summary **************
    7. Response Time (ms) Location
    8. Deferred srv*
    9. Symbol search path is: srv*
    10. Executable search path is:
    11. ModLoad: 00400000 0049c000 xyz.exe
    12. ModLoad: 773b0000 77554000 ntdll.dll
    13. ModLoad: 049c0000 049fa000 cyinjct32.dll
    14. ModLoad: 74fb0000 75002000 C:\Windows\SysWOW64\MSCOREE.DLL
    15. ModLoad: 76c80000 76d70000 C:\Windows\SysWOW64\KERNEL32.dll
    16. ModLoad: 75270000 7548c000 C:\Windows\SysWOW64\KERNELBASE.dll
    17. (6f28.5a1c): Break instruction exception - code 80000003 (first chance)
    18. eax=00000000 ebx=00000000 ecx=16810000 edx=00000000 esi=773b69fc edi=773b6a78
    19. eip=77461ee2 esp=008ff738 ebp=008ff764 iopl=0 nv up ei pl zr na pe nc
    20. cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
    21. ntdll!LdrpDoDebuggerBreak+0x2b:
    22. 77461ee2 cc int 3


    Da hat er eine Pause eingelegt. Als ich aber auf den grünen Pfeil für "Go" gedrückt habe, ist die Anwendung ganz normal gestartet und hat auch funktioniert.
    Leider weiß ich nicht in welcher Art mir WinDbg noch weiterhelfen kann.

    Vielleicht noch eine weitere Anmerkung: Heute Morgen hat mir der Visual Studio Debugger tatsächlich mal etwas anderes ausgespuckt, als die im Post #1 erwähnte Meldung.
    Es war zwar auch eine Fehlermeldung, aber besser als nichts.

    Quellcode

    1. System.Threading.SynchronizationLockException
    2. HResult=0x80131518
    3. Nachricht = Object synchronization method was called from an unsynchronized block of code.
    4. Quelle = <Die Ausnahmequelle kann nicht ausgewertet werden.>
    5. Stapelüberwachung:
    6. <Die Ausnahmestapelüberwachung kann nicht ausgewertet werden.>
    8. "xyz.exe" (CLR v2.0.50727: DefaultDomain): "C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll" geladen. Das Laden von Symbolen wurde übersprungen. Das Modul ist optimiert, und die Debugoption "Nur eigenen Code" ist aktiviert.
    9. Ein Ausnahmefehler des Typs "System.Threading.SynchronizationLockException" ist in Unbekanntes Modul. aufgetreten.
    10. Object synchronization method was called from an unsynchronized block of code.
    12. Unbehandelte Ausnahme: System.Threading.SynchronizationLockException: Object synchronization method was called from an unsynchronized block of code.
    13. at System.Resources.ResourceManager.TryLookingForSatellite(CultureInfo lookForCulture)
    14. at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)
    15. at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)
    16. at System.Environment.ResourceHelper.GetResourceStringCode(Object userDataIn)
    17. at System.Environment.GetResourceFromDefault(String key)
    18. at System.Runtime.InteropServices.ExternalException..ctor()
    19. at System.Runtime.InteropServices.SEHException..ctor()
    20. Das Programm "[38796] xyz.exe" wurde mit Code -1073741674 (0xc0000096) 'Privileged instruction' beendet.


    Vielleicht hat dazu noch jemand eine Idee.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „RiLo“ ()

    RiLo schrieb:


    (...) 'Das Laden von Symbolen wurde übersprungen. Das Modul ist optimiert, und die Debugoption "Nur eigenen Code" ist aktiviert' (...)

    (...) Vielleicht hat dazu noch jemand eine Idee (...)

    Kann es sein, dass das Debuggen mit der Einstellung „Optimieren” ausgeführt wird? Denn ich habe diese Optimierung mal testweise eingeschaltet und eine rudimentär ähnliche Fehlermeldung reproduziert/bekommen. Die Optimierung darf im Debugmodus nicht eingeschaltet sein - die ist nur für den Release gedacht. Zu finden ist das unter: Projekteigenschaften -> Kompilieren -> nach unten scrollen -> Erweiterte Kompilierungsoptionen => Optimierung Aktivieren (hier Häkchen weg)
    Das gleichzeitige Erscheinen von Dummheit und Unmündigkeit nach Immanuel Kant ist eines der schlimmsten Dinge, die einem Homo sapiens in geistiger Hinsicht widerfahren können, hat manchmal aber auch durchaus seine Vorteile.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Gregor Jasinski“ ()

    RiLo schrieb:

    (...)

    Wenn an der Projektmappe nichts geändert wurde und das vor 6 Monaten auf dem gleichen Rechner mit dem gleichen System problemlos lief, ist vielleicht doch was an dem ursprünglich installierten VS2019 gewesen, auf der Festplatte geblieben und nach der Neuinstallation weiterverwendet worden - ich glaube, es wird bei der Deinstallation nicht alles komplett gelöscht, einige Pfade und Dateien bleiben in Form von Artefakten auf der Platte, die müsste man finden und manuell löschen - da sollte man aber wissen, was man da tut, denn es kann schnell noch schlimmer werden ; ) Ich würde auf jeden Fall parallel zu VS2019 das neue, kostenlose Community VS2022 einfach mal so - probeweise - installieren, dann eine Projektkopie machen und das der IDE zum Laden und Ausführen mit Debuggen geben. Kostet ja nix, nur Zeit und Festplattenspeicher. Wie ich schon schrieb, die können koexistieren - ich benutze ja auch noch beide, bzw. habe VS2019 nicht deinstalliert, denn man weiß ja nie was kommt - in so einem Fall kann man dann mit der einen oder anderen Version des Studios das eine oder andere schon mal ausschließen. VS2019 ist bei einer Standardinstallation unter 'Programme (x86)' und VS2022 unter 'Programme', da gibt es aber noch andere Pfade und bestimmt auch jede Menge Einträge in der Registry, in der man so ohne weiteres nicht rumfummeln sollte. Ich würde es auch mit Framework 4.8 und 4.8.1 testen, 4.8 ist eigentlich die letzte Version, die laut Microsoft empfohlen wird, damit die heute erstellten Programme noch viele Jahre auf den PCs der Kunden lauffähig bleiben können.
    Das gleichzeitige Erscheinen von Dummheit und Unmündigkeit nach Immanuel Kant ist eines der schlimmsten Dinge, die einem Homo sapiens in geistiger Hinsicht widerfahren können, hat manchmal aber auch durchaus seine Vorteile.

    Dann würd ich es so machen:

    Backup machen, dieses testen; wenn es funktioniert, nutze das Backup

    VS schließen, danach den/die versteckten .vs-Ordner löschen, wenn der Fehler weg ist: Glück gehabt

    alle Projekte bis auf das Startprojekte entfernen, allen Eigen-Code aus dem Startprojekt löschen; wenn das funktioniert, Methodenrümpfe reaktivieren, aber Code-Verweise auf andere Projekte deaktivieren; später immer mehr reaktivieren (dazu das Backup immer wieder hernehmen), bis Du das Problem findest

    alle Controls aus dem Startprojekt entfernen; wenn das funktioniert, macht wohl ein Control ein Problem

    Verweise zu anderen DLLs löschen; wenn das klappt, ist wohl ne DLL schuld

    Wenn nix mehr außer einem scheinbar leeren, aber nicht funktionierendem Projekt übrig ist, dieses bereinigen, zippen, hochladen, dann testen wir das
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

    RiLo schrieb:

    VS2022 installiert (...) Der Fehler bleibt bestehen.

    Wenn sowohl VS2019 als auch VS2022 das gleiche machen, dann deutet es darauf hin, dass das Problem möglicherweise nicht im Visual Studio selbst, sondern in der Projektmappe liegt - vielleicht ist eine Inkompatibiltät wegen des Alters der Programme (wie alt sind sie denn?) entstanden - durch irgendein Update (egal, ob bei Windows 10 oder Visual Studio), das in den letzten 6 Monaten automatisch erfolgte, kann so etwas passieren. Eine andere Hypothese ist, dass in dem oder den Projektordnern irgendetwas von Visual Studio beim Assemblieren zerschreddert oder so verändert wurde, dass ein normales Debuggen nicht mehr möglich ist. Ja, Hypothese, denn es sind aufgrund fehlender Hintergrundinformationen nur Vermutungen - mehr nicht. Es gibt mehrere Möglichkeiten:
    • (a) man lässt sich sämtliche, unterschiedliche Errors (Nr+Text) des Debuggers ausspucken und sucht dann solange zeilenweise und akribisch nach Infos im Netz, bis man vielleicht auf etwas stößt, was einem hilft - könnte aber Tage oder Wochen dauern, bis man etwas findet oder eben auch nichts findet
    • (b) man holt sich einen Experten, der sich mit dem VS-Debugger auskennt und sich das vor Ort anschaut - kostet höchstwahrscheinlich Geld und eine Garantie für Erfolg gibt es nicht
    • (c) man wendet sich mit gut dokumentierten Informationen zu diesem Fall per eMail direkt an den Microsoft-Support, also den Hersteller der Suppe, der dann irgendwie reagieren muss/wird und vielleicht hilft, weil der Fehler intern bereits bekannt ist
    • (d) man lässt es sein, da der Aufwand, diese alten Dateien - die im Grunde genommen eigentlich funktionieren - mit der neuen Software zum Debuggen zu bewegen einfach zu groß ist - den Build kann man selbstverständlich auch ohne Debuggen machen - man kann in den Einstellungen sogar die Tasten umdefinieren: F5 ist dann z.B. „Starten ohne Debuggen” und Strg+F5 „Debuggen starten”
    Das gleichzeitige Erscheinen von Dummheit und Unmündigkeit nach Immanuel Kant ist eines der schlimmsten Dinge, die einem Homo sapiens in geistiger Hinsicht widerfahren können, hat manchmal aber auch durchaus seine Vorteile.

    Ich bin gerade dabei den Tipps von @VaporiZed nachzugehen.

    Jetzt habe ich zwei Dll's entfernt, welche nicht zum Stamm "System" gehören. Einmal die adodb (aus dem GAC) und einmal eine Dll für die Kommunikation per OPC. Nach Entfernen der adodb wurde mir auf einmal der ganze restliche Code rot unterstrichen. Beim darüberhovern kommt die Meldung "Es ist ein Verweis auf die Assembly "mscorlib, Version 2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" erforderlich, die den Typ "MarshalByRefObject" enthält. Fügen Sie dem Projekt einen Verweis hinzu."

    Will ich aber dem Projekt einen Verweis auf die mscorlib hinzufügen kommt die Meldung "Es konnte kein Verweis auf mscorlib hinzugefügt werden. Auf diese Komponente wird bereits automatisch durch das Buildsystem verwiesen."

    Auch das erneute hinzufügen der anderen beiden Dll's ändert nichts.

    Neu erstellen des Projektes und der Projektmappe hilft auch nicht.

    Meine Tipps sollten eigentlich eine Reihenfolge darstellen. Du scheinst aber codehaltigen Projekten die DLLs zu entziehen. Das ist extrem aufwendig, dann das Projekt zum Starten zu bringen. Also erst allen Code deaktivieren, dann testen, dann DLLs entfernen.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Guten Morgen,

    jetzt ist das Projekt komplett leer. Es ist nun lediglich noch die Startform (frm_Dateneingabe) vorhanden. Der Fehler erscheint trotzdem immer wieder.

    Gezipptes Projekt im Anhang. Ich hoffe, dass es richtig bereinigt ist.
    Dateien

    Dann ist was bei Dir kaputt. Bei mir startet es problemlos.
    Bilder

    • Kantenstraße.png

      3,76 kB, 1.262×912, 116 mal angesehen
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Das habe ich mir fast gedacht. Aber was könnte es jetzt noch sein? Allzu viel bleibt fast nicht mehr übrig.
    Habe ja, wie bereits oben erwähnt, schon einiges deinstalliert und wieder neu installiert.

    Ich habe das Projekt nun auf NET-Framework 4.0 hochgezogen. Jetzt geht es :huh:

    Verstehe trotzdem nicht warum es bei 3.5 nicht funktioniert hat.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „RiLo“ ()