Ursache für dauerhafte CPU-Auslastung finden

[Uwe Raabe]

Ist das Projekt zufällig ein MDI-Projekt und verwendet Actions?

[CodeX]

Zitat von Uwe Raabe:

Ist das Projekt zufällig ein MDI-Projekt und verwendet Actions?

Nein, "leider" nicht.

Zitat von TiGü:

Standard Version -> intergiert sich in IDE -> schlecht!
Trial/Pro Version -> kann, muss sich nicht integrieren -> gut!
von extern kompilierte Programm analysieren -> Ja!
die direkten Code-Stellen ausfindig zu machen -> geht mit der Pro Version. Man sagt über die Programmoptionen, wo die Quelltext-Dateien liegen und dann gibt's die zeilenweise Analyse.
Ist das dann optional und sollte bei der Installation deaktiviert werden? -> Ja!

Danke, dann werde ich das mal so machen und mich vorher erstmal zu AQTime einlesen. Hoffentlich komme ich damit auf den Grund.

Falls jemand noch einen anderen Ansatz weiß, was man z.B. direkt mit der Delphi IDE versuchen könnte, gerne her damit!
Oder wenn jemand noch eine Idee hat, was es mit der Stack-Info "TMethodImplementationIntercept" im Process Explorer auf sich haben könnte, auch gerne mitteilen.
Danke!

[TiGü]

Zitat von CodeX:

Zitat von Uwe Raabe:

Ist das Projekt zufällig ein MDI-Projekt und verwendet Actions?

Nein, "leider" nicht.

Ich nehme an, das Nein bezog sich auf MDI.
Bitte trotzdem mal alle TAction-Instanzen checken, ob da nicht doch irgendwo ein OnUpdate angemeldet ist, was dein Problem verursacht.
Ein Debuggen von TApplication.Idle und all der Aufrufe darin ist vielleicht auch noch ganz hilfreich, wenn du Timer und Threads ausschließen kannst.

Zitat von CodeX:

Oder wenn jemand noch eine Idee hat, was es mit der Stack-Info "TMethodImplementationIntercept" im Process Explorer auf sich haben könnte, auch gerne mitteilen.

Der Process Explorer schnappt sich einfach die erstbeste exportierte Funktion des Binary für den Mainthread, dass hat mit deinem Problem eher wenig zu tun.
Nimm mal ne neue und leere Applikation und öffne die im Dependency Walker oder Dependencies (https://github.com/lucasg/Dependencies).
Du wirst sehen, auch hier wird TMethodImplementationIntercept exportiert und der Mainthread wird in Process Explorer damit benannt.

[TiGü]

Ganz stumpf ist noch die Möglichkeit, das Programm auszuführen und mehrmals im Debugger anzuhalten (Pause).
Je nach Zufall landest du dann an der gesuchten "rechenintensiven" Codestelle.

Ein normaler Call Stack vom Mainthread sieht zumeist so aus:

Code:

:74e510cc win32u.NtUserWaitMessage + 0xc
:005c5e72 TApplication.Idle + $14E
Vcl.Forms.TApplication.HandleMessage
Vcl.Forms.TApplication.Run
Project2.Project2
:7607fa29 KERNEL32.BaseThreadInitThunk + 0x19
:76fd75f4 ntdll.RtlGetAppContainerNamedObjectPath + 0xe4
:76fd75c4 ntdll.RtlGetAppContainerNamedObjectPath + 0xb4

Das sollte bei dir dann abweichen, wenn du erfolgreich bist.

[CodeX]

Keine Verwendung von MDI oder TAction.

Ich habe alle Timer, die im gesamten Projekt vorkommen (Fremdkomponenten ausgenommen), in die Watch List hinzugefügt und das Programm im Debugger im Leerlauf angehalten: Alle Timer sind entweder Enabled:=False oder Inaccessible value, da in nicht initialisierten Forms oder Objekten.

Threads werden theoretisch verwendet, aber nicht automatisch nach dem Programmstart, sondern nur bei bestimmten Aktionen. Breakpoints bei deren Erstellung springen entsprechend auch nicht an. Der Process Explorer bestätigt das meiner Meinung ja auch, da dort die Auslastung im HauptThread liegt.

Wenn ich im Debugger auf Pause drücke, lande ich in der CPU Ansicht immer hier:

Code:

ntdll.RtlUserThreadStart:
775E3BE0 833DBC69697700   cmp dword ptr [$776969bc],$00

Darüber und darunter ist halt viel Assembler, aber keine Funktionsnamen o.ä. die mir irgendetwas sagen würden.
Lässt sich aus dieser Zeile schon etwas ableiten, was mir entgeht?

> Debuggen von TApplication.Idle
Was meinst Du damit genau? Im OnIdle Event von TApplication irgendwas einfügen, darauf einen Breakpoint setzen und schauen, was davor passiert ist? Oder wie?

[TiGü]

Für beide Fragen habe ich mal zwei kleine TeamViewer-Meetings aufgezeichnet, vielleicht wird's dann eher klar was ich von dir möchte.
https://drive.google.com/drive/folde...D6wFeYfGq1iese

How_to_Debug.tvs:
Der erste Thread in der Threadübersicht ist immer der Mainthread in der IDE.

How_to_Debug_2.tvs:
Debuggen der TApplication.Idle.
Voraussetzung: Project Options -> Delphi-Compiler -> Compiling -> Use debug .dcus muss auf True stehen.
Wenn deine IDE auf deutsch steht dann entsprechend die deutschen Begriffe.

[CodeX]

Oh, vielen Dank!

Das zweite Video hatte ich also im Prinzip zuvor richtig verstanden und auch geschaut, was danach passiert. (dazu gleich mehr)

Das erste Video hat mir aber schon mal ein bisschen weitergeholfen.
Der Haupt-Thread (TID auch mit Process Explorer abgeglichen), der die Auslastung verursacht landet beim Anhalten immer hier:

Code:

win32u.NtUserWaitMessage:
762E10C0 B80C100100       mov eax,$0001100c
762E10C5 BA10632E76       mov edx,$762e6310
762E10CA FFD2             call edx
762E10CC C3               ret               <------
762E10CD 8D4900           lea ecx,[ecx+$00]

Der zugehörige Stack Trace ist das hier:

Code:

:762e10cc win32u.NtUserWaitMessage + 0xc
:0070ec0b TApplication.Idle + $153
Vcl.Forms.TApplication.HandleMessage
Vcl.Forms.TApplication.Run

In diesem Teil von "TApplication.Run" lande ich auch, wenn ich von OnIdle weitergehe:

Delphi-Quellcode:

procedure TApplication.Run;
[...]
  repeat
    try
      HandleMessage;
    except
      HandleException(Self);
    end;
  until Terminated;
[...]

Dass die Anwendung auf Messages hört, überrascht mich jetzt eher nicht. Also ganz normales Verhalten? Oder sollte das so doch nicht sein?
Habe das mehrfach mit dem gleichen Ergebnis durchgespielt. Bringt es was, das ganz oft weiter zu wiederholen, in der Hoffnung, ein Mal wo anders zu landen beim Anhalten?