Delphi Rio "disconnected session"

[BigAl]

Hallo zusammen,

ich wundere mich, dass es so wenige Beiträge zu "disconnected session" gibt. Nach mehreren Wochen mit Visual Studio muss ich mich nun wieder mit der Delphi IDE rumplagen. Ich hatte heue bestimmt 10 mal das Problem mit "disconnected session" nach dem Start meines Programms. Das heißt jedes mal IDE "hart" beenden (Taskmanager), neu Starten und beten, dass es dieses mal wieder geht. Das macht echt kein Spaß. Geht das nur mir so? Mache ich irgendwas falsch?

Ich habe das Problem auf allen drei Entwicklungsrechnern. Es spielt dabei auch keine Rolle ob ich das Programm in der "Debug" oder "Release" Konfiguration starte. Und es ist auch egal ob ein simples Konsolenprogramm oder eine aufwändige VCL-Anwenung ist...

Die IDE spackt zwar an vielen anderen Stellen auch rum (vorhin hat Ctrl-D mal den kompletten Code durcheinander gewürfelt und ist danach komplett ausgestiegen) aber das mit der "disconnected session" nervt am meisten...

Wenn Ihr Tipps habt wie man das los wird wäre das cool. Ich bin hier echt am Verzweifeln. Ich hatte früher immer über die Visual Studio IDE gelacht und die Delphi IDE in den Himmel gelobt, aber ich hatte jetzt 3 Wochen Visual Studio und nicht einen Aussetzer...

Alex

[Amanda]

Ich verwende zum Debuggen nicht 64Bit um das Problem zu vermeiden.

[BigAl]

Zitat:

Zitat von Amanda (Beitrag 1461891)

Ich verwende zum Debuggen nicht 64Bit um das Problem zu vermeiden.

Ist leider keine Option für mich. 32 Bit wären schon aufgrund der benötigten Speichergrößen nicht möglich...

[himitsu]

Die DelphiIDE ist nunmal nur 32 Bit, also alles außer 32 Bit-Windows läuft somit praktisch immer über einen RemoteDebugger.

Ich kenn es aber auch bei 32 Bit, wo der Debugger abraucht und man dann die IDE nur noch hart abschießen kann, weil sie den Debugger beim Beenden auch beenden will, aber weil der nicht reagiert und somit nicht nochmal beendet werden kann ......... nja.

Zitat:

Zitat von BigAl (Beitrag 1461896)

Ist leider keine Option für mich. 32 Bit wären schon aufgrund der benötigten Speichergrößen nicht möglich...

Ein 32 Bit-Programm hat zwar virtuell nur maximal 2GB bzw. 3GB (im 32 Bit-Windows) oder fast 4GB (im 64 Bit-Windows), wenn man die Option aktiviert.
Und es gibt mehrere Wege auch noch viel mehr Arbeitsspeicher oder gar physischen RAM zu werdenden, wenn man denn will. (und der Admin das nicht verboten hat)

[BigAl]

Zitat:

Zitat von himitsu (Beitrag 1461922)

Die DelphiIDE ist nunmal nur 32 Bit, also alles außer 32 Bit-Windows läuft somit praktisch immer über einen RemoteDebugger.

Ich kenn es aber auch bei 32 Bit, wo der Debugger abraucht und man dann die IDE nur noch hart abschießen kann, weil sie den Debugger beim Beenden auch beenden will, aber weil der nicht reagiert und somit nicht nochmal beendet werden kann ......... nja.

Zitat:

Zitat von BigAl (Beitrag 1461896)

Ist leider keine Option für mich. 32 Bit wären schon aufgrund der benötigten Speichergrößen nicht möglich...

Ein 32 Bit-Programm hat zwar virtuell nur maximal 2GB bzw. 3GB (im 32 Bit-Windows) oder fast 4GB (im 64 Bit-Windows), wenn man die Option aktiviert.
Und es gibt mehrere Wege auch noch viel mehr Arbeitsspeicher oder gar physischen RAM zu werdenden, wenn man denn will. (und der Admin das nicht verboten hat)

Sind ja nicht nur die Speicher-Limits. Das Programm basiert halt an vielen Stellen auf 64 Bit. Wobei natürlich auch z.T. Arrays mit 20 GB oder noch größer aufgemacht werden. Ich könnte natürlich jetzt ein paar Wochen lang alles umschreiben weil Idera das nicht gebacken bringt und das denen in Rechnung stellen :-). Ist halt traurig wenn man mitverfolgt wie die langsam das gute Zeug verunstalten. Refactor usw. haben bei Emba/Idera ja noch nie wirklich gut funktioniert und die Umgebung instabil werden lassen. Code-/Error-Insight waren auch nie eine Stärke der IDE. Und mit dem neuen Style-Zwang ist alles noch viel schlimmer geworden. Ich hatte da Ende letzten Jahrs mal in Düsseldorf einen kurzen Plausch mit Marco Cantu diesbezüglich. Der hat leider auch nur alles mit einem Grinsen abgetan... Schade :-(

Der Bestand an Delphi-Applikationen ist halt bei mir sehr umfangreich. Diese laufen weltweit und ich muss für diese Support liefern und die bei Bedarf auch erweitern oder anpassen. Hintergundmodule portiere ich zwar mehr und mehr nach C++ aber immer wenn's grafische Benutzerschnittstellen gibt ist das RAD von Delphi nach wie vor meine Wahl Nr. 1. Bin halt mit der VCL aufgewachsen...

Weiterhin frohe Ostern

Alex

[mensch72]

Ich verwende&habe seit Jahren die RadStudio IDE nur noch in cleanen VMs installiert...

=> daher war&ist es naheliegend auch Windows(VCL/FMX/Console) wie Mac und Linux per PAserver&RemoteDebugger dann im einfachsten Fall im Win64 des HOST-PCs zu nutzen. (bzw. wenn man wie in vielen Emba-Demos gezeigt einen MAC als VM-HostRechner verwendet, dann eben eine 2.VM mit einem Win64, worin denn das ZielProgramm "alleine" läuft)

Richtig harte Hänger der IDE beim debuggen sind so sehr sehr selten und lassen sich notfalls per VM-Restart "sanft&sauber"(bezogen auf den HostRechner) lösen.

[t2000]

Ich habe das Problem auch. Komischerweise aber erst seit einigen Tagen.
Die Monate vorher habe ich diesen Fehler noch NIE gehabt.

[Uwe Raabe]

Zitat:

Zitat von t2000 (Beitrag 1462187)

Ich habe das Problem auch. Komischerweise aber erst seit einigen Tagen.
Die Monate vorher habe ich diesen Fehler noch NIE gehabt.

Ein Windows Update? Wäre nicht das erste Mal.

[t2000]

Kann sein. Mein Kompagnon hat die gleichen Probleme. Auch erst seit einiger Zeit.
Windows 10 Enterprise Version 1909 Build 18363.778 wird bei mir regelmäßig auf dem Laufenden gehalten. Das letzte Update kam erst gerade gestern. Wenn es daran liegt, muss es beim vorherigen Update gewesen sein.

Ich hatte ursprünglich vermutet, dass Delphi versucht einen Lizenzcheck "Zuhause" zu machen und dabei die Connection verliert. Aber klar, die Connection des Debuggers ist gemeint.

[Benmik]

Danke für den Hinweis. Ich hatte das jetzt auch schon 10 Mal, dachte aber, irgendwie läge es an mir. Delphi rumort im Hintergrund übrigens rum und verursacht eine merkliche Prozessorlast, das liegt nicht tot da.
Was ich vergaß: Auch 64-Bit.

[t2000]

Anhang 52341

[t2000]

Ich bekomme mein Programm nun gar nicht mehr im Debugger gestartet. Gestern Abend lief noch alles und heute morgen gar nicht mehr. Ohne etwas geändert zu haben.

[TiGü]

Mal spaßeshalber dein Windows auf einen Update-Zustand von vor ein, zwei Wochen zurückspielen?
Systemwiederherstellung als Stichwort.

[hoika]

Hallo,
vielleicht mal die bordbk260.dll neu registrieren?

[TurboMagic]

Wenn Subscription vorhanden evtl. mal eine offizielle SUpportanfrage über das SUpportportal (nicht QP in dem Fall!) an EMBT senden.
Dann schaut sich das dirékt jemand von EMBT an.

[t2000]

Habe erstmal ein paar andere Dinge gemacht ud danach wenige Zeilen weiter programmiert. Der nächste Start dann mit F8 diesmal hat funktioniert. Anschließend ging auch F9 wieder.
Supportanfrage war sofort draussen.
Mal abwarten wie es nächste Woche aussieht. Vom Gefühl macht es ein völlig willkürlichen Eindruck. Alles zufällig. Aber das glaube ich irgendwie nicht.

[ctavt]

Um den Thread nicht einschlafen zu lassen, möchte ich mich ebenfalls mitteilen.

Wir haben ebenfalls, seit wir mit 10.3.2 auf 64bit umgestiegen sind, damit Probleme, dass unsere Debug-Build Konfiguration mit sporadischem Auftreten den IDE-Fehler "Disconnected Session" wirft.

Einige Leute unseres Teams compilieren daher fürs Debuggen unter 32-Bit, da der Fehler dort niemals auftritt.

Da wir das Problem nun aber seit ca 1 Jahr haben schließe ich jegliche Zusammenhänge mit aktuellen Windows-Updates aus.

Ich habe hierzu ein Ticket aufgemacht auf der offiziellen Emba Seite [Bug RSP-30222], da wir den Umstieg auf 10.4 überdenken.

Ich weiß, es geht hier um "Rio", aber auch "Sydney" scheint diesen Fehler nicht zu beheben, ihn sogar zu verschlimmern,
da nun nicht nur die Anwendung abstürzt, sondern darauffolgend die IDE lahmlegt und über Windows abgeschossen werden muss.


mfg Chris

[softtouch]

Der selbe Fehler tritt auch bei 10.4.1 auf, heute schon 2 mal bei mir, und immer noch nirgends eine Lösung in Sicht...

[t2000]

Bei mit trat der Fehler seit Sommer nicht mehr auf.
Meine Supportanfrage ist inzwischen geschlossen, weil ich 2 Anfragen vom Support nicht beantwortet habe als ich im Urlaub war.

[Michael II]

Auf meiner Kiste konnte ich gar nie 64Bit debuggen. Es wurde immer die Fehlermeldung "disconnected" angezeigt.

Mit Microsoft Windows [Version 10.0.19042.610] und D10.4U1 klappt es nun immer. Wieso dem so ist, weiss ich nicht. Aber... :

Hier wird u.a. geschrieben, dass Delphi in solchen "disconnected" Fällen viel arbeitet... Dies ist bei mir auch so, wenn ich mit der Firewall bds.exe blockiere und dann ein 64Bit Programm debuggen will und das Programm schliesse. Auch die "disconnected" Meldung wird angezeigt.

Deshalb meine Frage...: Habt ihr überprüft, ob in der Firewall "Embarcadero Debugger Kernel" und "Embarcadero RAD Studio for Windows" für tcp Verbindungen zugelassen sind?

Die beiden Programme findet man im Ordner C:\Program Files (x86)\Embarcadero\Studio\21.0\bin:
"Embarcadero Debugger Kernel" : dbkw64_27_0.exe
"Embarcadero RAD Studio for Windows" : bds.exe

...und hoffentlich als "zugelassen" auch in den Firewall-Einstellungen.


netstat -b sollte während dem 64Bit Debuggen die beiden Programme (mit Verbindungsstatus HERGESTELLT) auflisten:

Code:

  Proto  Lokale Adresse         Remoteadresse          Status
  TCP    127.0.0.1:49769        DESKTOP-OK5F7RP:49770  HERGESTELLT
 [dbkw64_27_0.exe]
  TCP    127.0.0.1:49770        DESKTOP-OK5F7RP:49769  HERGESTELLT
 [bds.exe]
  TCP    127.0.0.1:49771        DESKTOP-OK5F7RP:49772  HERGESTELLT
 [dbkw64_27_0.exe]
  TCP    127.0.0.1:49772        DESKTOP-OK5F7RP:49771  HERGESTELLT
 [bds.exe]

[JWBokx]

Ich bin glucklig dieses gefunden zu haben!

Nog ein zufugging:
Unsere neue vriunscanner (Eset) hat auch ein firewall!
So auch dort zufugen!

[Michael II]

Ah gut ;-).
Hier in DP werden immer wieder "ich kann nicht mehr Win64 debuggen" Probleme geschildert. Ich bin ziemlich sicher, dass in den meisten Fällen eine Firewall fest auf der Leitung steht.