Einfrieren des Rechners

[zeras]

Guten Abend,

ich habe seit einiger Zeit das Problem, dass mein Rechner komplett einfriert, wenn ich im Debug Modus ein Programm starte. Das passiert nicht immer, aber am Tag 1-2 Mal.
Dann friert Delphi erst ein, manch andere Programme kann ich noch schließen, andere wiederum nicht mehr.
Dann hilft nur noch Einschalter lange Zeit drücken und Neustart.
Kann es sein, dass Delphi den kompletten Rechner lahmlegt?

[KodeZwerg]

Gibt es im Gerätemanager evtl. unbekannte Geräte?
Diesen Fehler kenne ich nur bei falschem/fehlenden HDD/Chipsatz Treibern.

edit:
ps:
evtl. mal einen RAM check (Speicherdiagnose) durchführen.
Defekter RAM kann auch eine Ursache sein....

[hoika]

Hallo,
welche Windows-Version?
Ev. die Entwickler-Version (Fast ring)?

[Luckie]

Wann hat das angefangen?

[Neumann]

Das Problem hatte ich auch schon mal, Ursache unbekannt und warum es dann wieder verschwunden ist ebenfalls.

Ich habe mir in der Zeit immer damit beholfen Delphi nur einen Prozessor zuzuweisen, dann kam das Problem kaum noch. Ist aber lästig, da man es bei jedem Neustart wieder manuell einstellen muss.

[freimatz]

Hier in Firma (neuestes Delphi) habe ich dass Delphi ab und zu einfriert, aber nach etlichen Sekunden wieder kommt.

Woanders mit Berlin friert Delphi auch ein, kommt aber auch nach 10 Minuten nicht mehr. Hier kann ich es recht zuverlässig reproduzieren wenn ich ein DUnit-test mit UI starte, dann zu delphi wechsele und dort dann Strg+Umsch+F drücke (Suche)

[ghubi01]

Hallo,

ich habe ein ähnliches Problem.
Die IDE friert immer beim debuggen von Win32 Bit Anwendungen ein. Bei Delphi Tokyo und Rio.
Ganz selten, dass es mal ohne Probleme startet. War von Anfang an schon so. :?

Es reicht dann aber über den Process-Explorer https://docs.microsoft.com/de-de/sys...ocess-explorer nur die Project1.exe zu killen.

Mit Zielplattform Win64 Bit läuft alles reibungslos.

Bei Delphi XE6 gibt es mit den Zielplattformen Win32 und Win64 Bit keine Debugger-Probleme.

[zeras]

Zitat:

Zitat von KodeZwerg (Beitrag 1456039)

Gibt es im Gerätemanager evtl. unbekannte Geräte?
Diesen Fehler kenne ich nur bei falschem/fehlenden HDD/Chipsatz Treibern.

Der Laptop ist relativ neu (Lenovo Thinkpad). Vielleicht sind da noch Treiber, die nicht sauber sind.

Zitat:

Zitat von KodeZwerg (Beitrag 1456039)

edit:
ps:
evtl. mal einen RAM check (Speicherdiagnose) durchführen.
Defekter RAM kann auch eine Ursache sein....

Geht das mit Windows Bordmitteln oder benötige ich ein extra Programm?

Zitat:

Zitat von ghubi01 (Beitrag 1456084)

Es reicht dann aber über den Process-Explorer https://docs.microsoft.com/de-de/sys...ocess-explorer nur die Project1.exe zu killen.

Mit STRG-ALT-ENTF geht auch nichts. Ich muss den Einschalter längere Zeit drücken, damit der Rechner aus geht und dann starte ich neu.

Zitat:

Zitat von hoika (Beitrag 1456040)

Hallo,
welche Windows-Version?
Ev. die Entwickler-Version (Fast ring)?

Windows 10/64 1909

Zitat:

Zitat von Luckie (Beitrag 1456041)

Wann hat das angefangen?

Ich hatte zuerst 10.3.3 drüberinstalliert, ohne die Registryeinträge zu löschen. Da danach das ganze Android weg war, habe ich RAD nochmals neu installiert. Android ist zwar immer noch nicht da, aber im Moment benötige ich das nicht.
Vermeintlich nach der 10.3.3 Installation


Zusatz:
Habe mit Lenovo VANTAGE auf Updates prüfen lassen und eine Reihe von Updates wurden angezeigt. Diese habe ich auch installiert. Auch ein BIOS Update war mit dabei.
Bei meinem anderen Laptop (ASUS) habe ich noch keine Meldung bekommen, dass ich Treiber neu installieren sollte.
Sind bei Lenovo vielleicht "Bananentreiber" drauf, die erst beim Kunden reifen müssen?
Ich meine, dass sich schon einmal ein BIOS Update gemacht hatte. Das wäre dann schon das 2. innerhalb von 4-5 Monaten.

[ghubi01]

Hallo,

ich habe die Ursache für meine Debugger-Probleme gefunden.
An meinem PC war über USB ein ASUS-Tablet (ME173X) angeschlossen.
Nachdem ich es "abgeklemmt" hatte, funktioniert auch der Debugger für Win32 wieder.
Nach erneutem Anschließen trat der Fehler wieder auf.

Merkwürdig. Wieso kommen sich der Debugger für die Win32 Zielplattform und das angeschlossene Tablet in die Quere?
Ich habe hier nur eine VCL-Anwendung mit Form, Memo und einem Butten zum testen verwendet.

[DieDolly]

Zitat:

Geht das mit Windows Bordmitteln oder benötige ich ein extra Programm?

Nein.

https://www.memtest86.com/

Zitat:

ich habe seit einiger Zeit das Problem, dass mein Rechner komplett einfriert, wenn ich im Debug Modus ein Programm starte.

Ich würde an diesem Gerät gar nicht erst groß rumtesten sondern erstmal einen Cinebench R20 oder Superposition Unigine laufen lassen. Wenn da nix einfriert, liegt es vermutlich (ohne Gewähr) an Delphi.
Bevor hier Aufschreie kommen: vergiss Prime95 sofort wieder.

[Michael II]

Ich kenne dieses Verhalten von einem 32Bit Delphi Programm P (Release); es trat bei sehr wenigen (<1%) Kunden auf; dort aber immer wieder.
Das Problem trat von täglich mehrmals bis alle paar Tage auf. P blieb mehrere Sekunden oder viel länger (auch nach Minuten nicht zurück) hängen; auch auf dem aktuellen Win10 Release.

Das Problem trat auf seit Delphi Carnival/Rio und vorher nie.

Das Programm lief dabei nicht in eine Exception.

Auf meinen Compis (u.a. auf zwei Windows Server Systemen, P im Dauerbetrieb) lief P absolut problemlos. Ich habe insgesamt xx Wochen "verbraten" bei der Suche und bei Anpassungen (was 20 jährigem Code durchaus auch gut tun kann ;-)).

Schliesslich habe ich mit Eurekalog und v.a. auch dank Dauer-Kundenfeedback das Problem beseitigen können.

Das Programm blieb bei den betroffenen Kunden immer wieder in
C:\Windows\WinSxS\x86_microsoft.windows.common-controls...\comctl32.dll
hängen, immer im Zusammenhang mit TMemo.

Ich habe natürlich keine Ahnung, ob bei deinem Delphi das gleiche Problem vorliegt. Viel Spass beim Loggen... ;-).

[Uwe Raabe]

Zitat:

Zitat von Michael II (Beitrag 1456312)

Das Programm blieb bei den betroffenen Kunden immer wieder in
C:\Windows\WinSxS\x86_microsoft.windows.common-controls...\comctl32.dll
hängen, immer im Zusammenhang mit TMemo.

Welche Einstellungen stehen denn auf der Seite Manifest in den Projektoptionen -> Anwendung?

[Billa]

Hallo,

das Problem trat bei meinem Firmenrechner (mit Rio und Tokyo) vorzugsweise beim Debugging auf: der Rechner kam manchmal erst nach über einer Minute "wieder".
Ursache war wohl ein kleines Dienstprogramm "Flow.exe" aus dem "HP-Audio Controls Control Panel". Das Ding scheint Lautstärken in Browserfenstern zu steuern. Seitdem in der IDE das News-Fenster beim Start und diese Anwendung "totgelegt" sind, ist das Problem weg.

[freimatz]

Zitat:

Zitat von Billa (Beitrag 1456332)

Seitdem in der IDE das News-Fenster beim Start ... "totgelegt" sind, ...

Wie macht man das?

[philipp.hofmann]

Schau dir mal die Beschreibung unter
https://www.danielwolf.eu/blog/2015/...lkommens-seite
an, da ist neben einer definitiv sinnvolleren Willkommensseite auch beschrieben, wie man die Default-News-Seite deaktiviert.

[Michael II]

Zitat:

Zitat von Uwe Raabe (Beitrag 1456324)

Welche Einstellungen stehen denn auf der Seite Manifest in den Projektoptionen -> Anwendung?

Hoi Uwe
und Danke.

Manifestdatei: Automatisch erzeugen, Laufzeit Themes EIN, DIP: "Monitor" wie auch mit "Monitor V2" veröffentlicht, Als Aufrufer, UI-Zugriff AUS, Benutzerdefiniertes Manifest LEER

Gruss
Michael

[Uwe Raabe]

OK, dann liegt es vermutlich nicht an einer alten comctl32.

[zeras]

Da sich das Problem durch Updates von Windows, BIOS etc. nicht lösen lies, habe ich die Info weiter oben genutzt.
Ich stelle fürs Debuggen von Win32 auf Win64 um. Seitdem hängt sich Delphi nicht mehr beim Debuggen auf.
Im Manifest habe ich Unterschiede zwischen 32 und 64. Woher die kommen, weiß ich leider nicht.
Bei 64 steht:
Manifestdatei: Automatisch erzeugen
Laufzeit-Themes ist nicht aktiviert
DPI-Unterstützung -> Keiner
Ausführungsebene -> Als Aufrufer
UI-Zugriff ist deaktiviert

Bei 32 steht:
Manifestdatei: Automatisch erzeugen
Laufzeit-Themes ist nicht aktiviert
DPI-Unterstützung -> Über Monitor v2
Ausführungsebene -> Als Aufrufer
UI-Zugriff ist deaktiviert

Sollte der Unterschied "DPI-Unterstützung" das Problem ausmachen?