VS 2005 - Einzel Debugging führt zum Blockieren des Programms

Hallo 😃

Ich habe seit längerem das Problem, dass wenn ich mit der Entwicklungsumgebung Visual Studio 2005 Einzeldebugging (Taste F10, oder F11) im Sourcecode ausführen will, mein Programm blockiert und ich nicht einmal eine Zeile debuggen kann. Ich muss jedes Mal meine USB Verbinung zum Gerät abziehen, damit VS 2005 sich von diesem Fehlerfall erholt.

Es kommt immer die Fehlermeldung > Fehlermeldung:

Microsoft Visual Studio ist ausgelastet,... wartet auf den Abschluss eines interen Vorganges.

Fehlermeldung:
Für die aktuelle Position ist kein Quellcode verfügbar! erscheint, nach dem ein Neustart des Gerätes erfolgte und der Unterbrechung der USB Verbindung passierte.

Selbst bei den Debugging Einstellungen habe ich nach etwas gesucht um die Fehler zu legalisieren, aber bis jetzt ist keine Verbesserung in Sicht.

Kann mir jemand weiterhelfen, um die Ursache meines Problems zu lösen?

Vielen Dank für Eure Bemühungen!

Ich vermute jetzt mal, daß sich Dein Quelltext auf einem USB-Laufwerk befindet.
VS hat manchmal Probleme mit USB. Manchmal werden da auch eingebundene Projekte und Verweise nicht mehr gefunden.

Ich habe meine Projekte prinzipiell immer auf einer eingebauten Festplatte.
Da habe ich keine Problem.

Hallo san-software,
mein Quelltext befindet sich nicht auf einem USB Laufwerk, sodass dies nicht die Ursache des Problems sein kann. Trotzdem Danke für deine Anregung!

Dann hast Du möglichweise ein Problem in Deiner Windows-Installation.
Vermutlich blockiert dann ein Gerät, das Du am USB hängen hast deinen Zugriff auf Deine Festplatten. VS will dann wohl so lange warten, bis wieder Daten von der Platte kommen.
Durch das Entfernen des USB-Gerätes wird dann der Plattenzugriff wieder freigegeben, aber VS dann wohl intern schon abgebrochen.

Versuche doch einfach mal zu arbeiten, wenn kein USB-Gerät angeschlossen ist.
Dann müßte das Debugen eigentlich funktionieren.

Wenn das so ist müßtest Du durch probieren einfach mal feststellen welches Gerät den Fehler verursacht. Wenn das eine Festplatte oder USB-Stick ist, dann das Ding mal komplett neu formatieren.

Wenn es dann nicht klappt, dann fällt mir eigentlich nur noch ein, das komplette SYstem platt zu machen und neu hochzuziehen.

Ich vermute eher, dass ein Handle offen bleibt bzw. nicht richtig geschlossen wird und sich das eben auf das USB Gerät bezieht.
Dadurch bleibt die Anwedung hängen. Beim Reject wird das Handle zwangsweise vom System abgeschossen und kann dann wieder verwendet werden.

Durchaus möglich: Treiberproblem.

Wir reden hier aber auch von einer 10(!) Jahre alten Entwicklungsumgebung, die streng genommen Technik der letzten 20 Jahre inne hat.
Ob da nicht mal ein Umstieg angebracht wäre..?

Hallo Abt,
wie kann ich dieses Hängen der Anwendung durch die USB Verbindung verhindern?

Wenn Du mit Deinem Code auf den Treiber (=> Das USB Gerät) zugreifst kann es durchaus sein, dass Du selbst der Verursacher bist, weil Du nicht korrekt mit den Ressourcen umgehst.
Hab aber leider keine Glaskugel 😉

Irgendwie kommen wir hier scheinbar in falsche richtugnen weil mache_a nicht ganz erzählt was da passiert.

Aus dem VS.NET 2005 und USB und Device folgere ich mal auf Entwicklung für Windows Mobile.
Und da kann es durchaus zu problemen führen wenn da irgendwas auf dem gerät blockiert.

Da kannst du VS keinen Vorwurf machen.
Entgegen meinem Vorredner macht es aus meiner Sicht keinen Unterschied ob du deine VS Version aktualisiert. (Updates haben ausser neuen Problemen für keine Software der Welt noch nie irgendwas gebracht, deswegen nutze ich XP SP3 bis zu dem Tag der mein letzter ist)

Wenn dein ausfühbarer Code den High-Level/UserLevel Bereich verlässt und Low-Level/DeviceDriver Code ausgeführt wird kann dir VS nicht mehr wirklich helfen.
(Wie denn auch ohne .pdb Symbole und der Tatsache das hier ASM und nicht IL Code ausgeführt wird)

Es gibt aber ein paar SDK/Remote Debugger Techniken die dir helfen könnten:
Ich finde hier ist es wiefolgt ganz gut zusammen gefasst:

How to test a driver at runtime using Visual Studio

Summary: Irgendwo geht dein USB Treiber nicht aus dem Interrupt und das System wartet, dank der NT Architektur aber auch nur singulär, das kann tatsächlich daran liegen weil du ihn via debugger beobachtest(heisenbergsche unschärfe relation, kennt jeder aus der grundschule)

Tritt das Problem auch ohne Debugger auf?

Und damit sich wirklich niemand ein Beispiel daran nimmt, hier noch der Hinweis auf die Warnung von Microsoft, Windows XP einzusetzen: The Risk of Running Windows XP After Support Ends April 2014. Das Bild aus dem Artikel bezüglich der Infektionsraten sagt alles: