Ursache für dauerhafte CPU-Auslastung finden

[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?

[Uwe Raabe]

Das WaitMessage wird am Ende von Idle aufgerufen. Es ist also durchaus normal wenn ein Programm dort steht.

Ich würde mal das Idle selbst analysieren. Dort können z.B. im FOnIdle oder DoActionIdle ein paar CPU-lastige Arbeiten stattfinden.

Übrigens ist die Angabe 0,1% - 0,2% CPU-Auslastung in Relation zu der Anzahl der verfügbaren logischen Prozessoren zu sehen. Bei einem Zweikern-System ist 1% wenig, bei einem 64-Kern System ist damit quasi ein Kern ausgelastet.

[TiGü]

Naja, gesamt gesehen hast du ja eine Auslastung von 2-3 Prozent auf einen Kern, du hattest es vorne irgendwo erwähnt.
Du müsstest also bei 100 zufälligen Pausieren in zwei bis drei Fällen zur betreffenden Codestelle kommen.
Wie ich oben sagte...ist halt ne sehr stumpfe Methode und mit AQTime wirste schneller zum Ziel kommen.

Deine Applikation sendet oder empfängt TCP oder UDP Kommunikation?

[himitsu]

Wenn dauern Messages reinkommen (z.B. weil irgendwer massiv mit Broadcasts um sich wirft), dann könnte man das mal mitzählen/loggen.
TApplicationEvents.OnMessage

* aber OnMessage bekommt nur PostMessage mit, exclusive WM_WIMER
* und wenn irgendwo Messages außerhalb der VCL verarbeitet werden, dann geht das auch unter (z.B. haben MessageBox und Open-/SaveDialoge innen eine eigene Message-Loop, so lange der Dialog angezeigt wird)
* und für SendMessage bräuchte man einen anderen Hook

[Monday]

Könnte ein Profiler hier weiterhelfen?!

[CodeX]

Ich habe jetzt mal analysiert, wo/wie die Messages in der Anwendung verarbeitet werden. Es existiert eine zentrale Prozedur, wo alle Messages erst durchgehen:

Delphi-Quellcode:

Application.HookMainWindow(HookAppProc);

[...]

function TKlasse.HookAppProc(var Msg: TMessage): Boolean;
begin
  OutputDebugString(PChar('### MSG App ' + Msg.WParam.ToString +'/'+ Msg.LParam.ToString)); //Das habe ich jetzt hinzugefügt
  Result := False; //Should always be False unless we don't want the default message handling
  case Msg.Msg of
    WM_SIZE: ...
    WM_CLOSE: ...
    WM_SYSCOMMAND: ...
    ...
  end;
end;

Ich glaube, das an sich sollte nicht das Problem sein, aber die neu hinzugefügte Debug-Zeile haut quasi ununterbrochen "0/0" Meldungen raus und tatsächlich gehen da offenbar ununterbrochen "leere" Messages durch (also in Msg ist alles 0). In der genannten Funktion passiert damit nichts, da es nach der case Abfrage gleich wieder rausspringt, aber vielleicht liegt das Problem dennoch hier?
Ist es normal, dass ununterbrochen leere Messages reinkommen? Wenn nicht, habe ich eine Chance, die Quelle der Messages herauszufinden (oder zumindest ob von außerhalb oder von einer anderen Stelle im Projekt)? Vielleicht kommt ja dann genau hier AQTime ins Spiel?