D11 : Programm hängt zieht 25% CPU bei UI Aktualisierung

[stalkingwolf]

ich habe ein etwas merkwürdiges Verhalten eines Programmes.
Wir haben diverse Programme von D6 auf 11 portiert was auch ganz gut funktioniert hat.
Nun habe ich ein Programm was sich merkwürdig verhält wenn es die UI aktualisieren soll.
Z.b Progressbar +1 oder TLabel.caption setzen, hängt das Programm mit einer CPU Auslastung von 25% ( ein Kern ).
Minimiere ich das Programm und maximiere das Programm, dann läuft es weiter.

Das Problem habe ich nur auf ein paar Kunden PCs (Windows 10). Leider auf einem bei uns in der Firma. Damit ist das debuggen extrem schwer.
Ich habe das Projekt schon komplett neu erstellt. Keine Änderung. Da es um relativ viele Units gibt welche untereinander verknüpft sind, ist es auch schwer Teile zu isolieren. Ich habe aber auch aktuell keine Idee wonach ich gezielt suchen soll.

auf Stackoverflow habe ich https://www.delphitools.info/downloa...ler-changelog/ gefunden.
Leider startet es unsere Programme nicht bzw. gibt eine Zugriffsverletzung.

Jemand hier eine Idee oder Ansatz wie ich das lokalisieren kann.

[himitsu]

Erstmal, bezüglich Debuggen von GUI-Sachen, am besten mit dem RemoteDebugger, von einem anderen PC aus.

Ansonsten auch mal mit einem Profiling Tool, ala AQTime, schauen wo die CPU-Zeit drauf geht.

[Sinspin]

Hallo,

Das klingt als wenn sich Handler für Window Botschaften gegenseitig fertig machen.
Visuell sind Delphi Komponenten im Einsatz?

Da sind ettliche Delphi Generationen dazwischen.
In alten Delphis brauchte man noch

Delphi-Quellcode:

SetWindowLong(Handle, GWL_EXSTYLE, GetWindowLong(Handle, GWL_EXSTYLE) or WS_EX_APPWINDOW);

um die Dialoge ordentlich dargestellt zu bekommen.
Oder selber implementierte Nachrichten Handler für modernere Standard Nachrichten, um diese verarbeiten zu können.

Das Problem wird sicher überall existieren und fällt aber mit bestimten Konfigurationen mehr auf.

[stalkingwolf]

Zitat:

Zitat von Sinspin (Beitrag 1517868)

Hallo,

Das klingt als wenn sich Handler für Window Botschaften gegenseitig fertig machen.
Visuell sind Delphi Komponenten im Einsatz?

ja und VirtualStringTree. Aber das nutzen wir auch in anderen Programmen und haben dort nicht diese Probleme.
Einzig AcroPDF ist vorhanden, aber das habe ich alles entfernt und das Problem tritt dennoch auf.

AQTime werde ich einmal testen ob mir das etwas sinnvolles ausgibt.

[jaenicke]

Ich würde zunächst einmal schauen, ob der Window Detective in dem Moment, wenn es hängt, die Abarbeitung von massenhaft Messages anzeigt. Das kann schon Hinweise geben.

[stalkingwolf]

keins der beiden Programme zeigt mir in dem Moment was an. Kommen keine Einträge.

Nur ein Problem habe ich entfernt indem ich application.processmessages entfernt habe.
Das nutzen wir eigentlich aber noch relativ häufig.

Edit : Was mir bei dem Programm auch auffällt. Alle MessageDLG und showmessage landen hinter dem Programm.
Aber das Programm ist nicht stayontop.

[Stevie]

ProcessExplorer als Admin starten - Rechtsklick auf den entsprechenden Prozess - Properties - Threads Tab und dort den Thread raussuchen, der die CPU verbrennt - selektieren und auf Stack klicken. Dort ruhig bisschen auf Refresh hämmern und beobachten, was da so auftaucht. Kann unter Umständen schon einen Hinweis geben.

Wenn remote debuggen auf den Rechner bei euch in der Firma möglich ist - über die IDE connecten und dann den entsprechenden Thread beobachten.

[Michael II]

Ich würde deine hängenden Projekte mal mit zum Beispiel Eurekalog laufen lassen. Das kann bei Hängern sehr helfen.
Delphi IDE Menu Projekt > Eurekalog Optionen unter "Features > Hang Detection" "gewünschte" Zeit einstellen.

Die Meldungsdialoge verhalten sich seit irgendwann XE nicht mehr genau so wie bei D6/7. Da musst du entweder deinen Code umbauen oder die Dialogfunktion so anpassen, dass sich deine App unter den neueren Delphis wie zu D6/7 Zeiten verhält. Sehr wahrscheinlich wird dies helfen:
Application.NormalizeTopMosts;
Application.RestoreTopMosts;

Zum Beispiel so:

Delphi-Quellcode:

function MessgeBoxDlg(const Msg: string; DlgType: TMsgDlgType; Buttons: TMsgDlgButtons; HelpCtx: Longint): Integer;
begin
  Application.NormalizeTopMosts;
  result := VCL.Dialogs.MessageDlg(Msg, DlgType, Buttons, HelpCtx);
  Application.RestoreTopMosts;
end;

Danke jaenicke für den Windows Detective Tipp - kannte ich nicht.

[stalkingwolf]

Zitat:

Zitat von Michael II (Beitrag 1517892)

Delphi-Quellcode:

function MessgeBoxDlg(const Msg: string; DlgType: TMsgDlgType; Buttons: TMsgDlgButtons; HelpCtx: Longint): Integer;
begin
  Application.NormalizeTopMosts;
  result := VCL.Dialogs.MessageDlg(Msg, DlgType, Buttons, HelpCtx);
  Application.RestoreTopMosts;
end;

Das bringt leider nichts.

Generell frage ich mich
a) Warum nur das Programm und nicht die anderen 20 die wir portiert haben?
b) Warum nur auf einigen Rechnern?

[Michael II]

Zitat:

Zitat von stalkingwolf (Beitrag 1517896)

Das bringt leider nichts.

Generell frage ich mich
a) Warum nur das Programm und nicht die anderen 20 die wir portiert haben?
b) Warum nur auf einigen Rechnern?

Windowsmeldungen werden nicht überall gleich "nett" abgearbeitet ;-). Ich hatte jetzt beim Wechsel auf D11 auch ein paar Probleme, welche leider nur auf einigen Maschinen auftraten und seit Delphi 2 nie. Und ich behaupte damit nicht, dass D11 das Problem ist.

Das mit den Meldungsfenstern hinter dem Hauptfenster. Falls die Meldungsfenster nach dem Restore der App hinten landen: Falls in diesem Fall NormalizeTopMosts; RestoreTopMosts; nix bringt: Ich habe eine (funktionierende) Bastellösung: Via Application.Components durch alle Forms wühlen und jene mit StayOnTop und dann noch jene mit Classname TMessageForm nach vorn bringen. Aber ich poste das hier nicht, da sicher jemand dann mit einem Einzeiler kontert, welcher das Problem auch und wesentlich schöner löst ;-).

Und das mit dem "Hänger". Hast du nun mal mit Eurekalog gecheckt, was aufgezeichnet worden ist?