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.