Ursache für dauerhafte CPU-Auslastung finden

[CodeX]

Ich habe hier ein relativ großes Delphi-Projekt vor mir, wo das Programm minimiert im Tray ohne jegliche Aufgabe eine dauerhafte CPU-Auslastung von 0,1% - 0,2% im Task-Manager anzeigt (andere im Hintergrund laufenden Anwendungen haben 0%). Das mag erstmal nicht schlimm erscheinen, aber normalerweise ist das ein Zeichen dafür, dass irgendetwas nicht passt und dann an anderer Stelle Probleme machen könnte.

Ich frage mich nun, wie ich die Ursache herausfinden kann.

• Zunächst habe ich es mir mit dem Process Explorer angeschaut. Dort sehe ich mehrere Threads der Anwendung.
• Der Thread mit der niedrigsten TID (Hauptthread?) schwankt durchgehend zwischen 0.10 und 0.22 herum.
• In der "Start Address" Spalte steht Name.exe!TMethodImplementationIntercept+0x... Was ist das?
• Der Stack für diesen Thread zeigt zwar eine Liste mit 27 Einträgen an, aber diese beziehen sich mit Ausnahme des genannten Eintrags auf Windowskomponenten, sodass ich dadurch auch nicht schlauer werde.
• Im Debugger sehe ich im Threads-Tab alle Threads, die auch im Process Explorer angezeigt wurden, also auch den betroffenen Thread, aber scheinbar kann man dort nichts damit machen (State: Runnable; Status: [leer]).

Wie komme ich jetzt weiter? Kann ich in der IDE irgendwie einen besseren Stack Trace als per Process Explorer anzeigen lassen? Sowas wie madExcept nach einer Exception anzeigt, nur eben im laufenden Betrieb ohne Fehler?
Oder komme ich irgendwie anders weiter?

[himitsu]

AQTime?



Ein Thread hat auch einen Parent-Thread.
Ich glaub der PE sollte dazu auch was anzeigen.

Mit etwas Glück wurde auch der Stacktrace beim Erstellen des Threads gespeichert, so sieht man dann wer den Thread erstellt hat und bekommt so die Antwort wofür der Thread sein soll.

[Sinspin]

Hallo, das ist mir auch schon aufgefallen. Ging vor gut einem Monat los. Ich denke ein Windowsupdate oder der Windows Defender sind schuld an der höheren CPU last. Es sind auch nicht nur Delphi Programme betroffen.

Für...

Zitat von CodeX:

• In der "Start Address" Spalte steht Name.exe!TMethodImplementationIntercept+0x... Was ist das?

...hilft erstmal Tante Google weiter. Da gibt es ein paar interessante Infos, die bisher beste ist aus meiner Sicht:
unwanted-export-tmethodimplementationintercept

[CodeX]

Zitat von himitsu:

AQTime?

Vermutlich könnte mir das weiterhelfen. Habe jetzt ein bisschen was dazu nachgelesen und ein Video bei YT angeschaut. Im GetIt sind 262 Pakete vorhanden, aber AQTime ist nicht darunter. Bei den Embarcadero Downloads finde ich nur Versionen für Delphi bis XE8.
Wo kriege ich denn eine funktionierende Standard Version für 10.3 her?

Zitat von himitsu:

Ein Thread hat auch einen Parent-Thread.

So wie ich das deute, handelt es sich ja um den Main-Thread, also um das Hauptprogramm an sich.

Zitat von Sinspin:

...hilft erstmal Tante Google weiter. Da gibt es ein paar interessante Infos, die bisher beste ist aus meiner Sicht:
unwanted-export-tmethodimplementationintercept

Ich habe natürlich als erstes danach gesucht, aber es schien mir eher eine generische Fehlerquelle zu sein, also dachte ich, die aus etwas Anderem resultiert. Da ich bei meiner Recherche auch Rtti als Stichwort gefunden habe, habe ich auch geschaut, ob ich hier etwas in der Richtung im Projekt anpassen kann. Da Rtti in dem Projekt gänzlich unerwünscht ist und das Programm nur unnötig aufbläht, wurde es soweit es ging aus dem Projekt entfernt. Da dies ja leider nicht mehr zentral geht, ist in jeder Unit ein Include von diesem Code enthalten:

Delphi-Quellcode:

{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

Wenn man es irgendwie noch besser und komplett entfernen könnte, bitte sagen!
Ich habe den Teil dann testweise auskommentiert und neu kompelliert, um auszuschließen, dass genau dieses Entfernen etwas damit zu tun hat, aber das CPU-Ergebnis war das gleiche. Lediglich die Exe ist um 10% angewachsen.

Deine verlinkten Infos sind sehr interessant, aber ich weiß nicht, ob mich das weiterbringt:
Ich kann nicht auf eine Delphi-Version vor XE5 wechseln und es handelt sich bei mir nicht um eine DLL.
System.Rtti wird im Projekt nirgends eingebunden. Wahrscheinlich durch irgendeine andere System-Unit oder Komponente.
Die einzige dort empfohlene Option wäre, die System.Rtti zu bearbeiten und den TMethodImplementationIntercept Teil (oder nur die exports Zeile?) auszukommentieren. Das erscheint mir ein bisschen wie mit der Brechstange. Gibt es vielleicht noch irgendeinen anderen Ansatz? Wenn wirklich Rtti Schuld ist, dann Rtti irgendwie komplett aus dem Projekt verbannen?

[venice2]

Darf deine Anwendung auch etwas tun?
0,1% - 0,2% ist doch gar nichts.
Deshalb nach einen angeblichen Fehler zu suchen ist etwas suspekt.
just my 2 cent!

[CodeX]

Zitat von venice2:

Darf deine Anwendung auch etwas tun?
0,1% - 0,2% ist doch gar nichts.
Deshalb nach einen angeblichen Fehler zu suchen ist etwas suspekt.
just my 2 cent!

Wenn die Anwendung etwas tun soll, dann darf sie das auch. Hier tut sie im minimierten Zustand aber nichts.

Wenn das jeder Prozess im Hintergrund so tun würde, dann wäre die CPU dauerhaft ausgelastet. Alle anderen inaktiven (Hintergrund-)Prozesse sind ja konstant bei 0%. Warum dann meiner nicht? Warum ist das ein "angeblicher" Fehler? Eine Anwendung, die nichts tut und nicht sichtbar ist, darf nicht dauerhaft CPU-Leistung fordern.

Zudem musst Du bedenken, dass die Angabe 0,2% bei (in meinem Fall) 8 Kernen und damit 16 logischen Prozessoren, einen davon zu 3,2% auslastet. Ohne etwas zu tun wohlgemerkt.

[Rolf Frei]

Irgendwo hast du ja einen "Idle" Loop drinnen, der auf eine Eingabe wartet um aktiv zu werden. Was passiert denn da in dem Loop genau?

[freimatz]

procmon?

Vielleicht bekommt die App Windows-Botschaften von ausserhalb.

[CodeX]

Zitat von freimatz:

procmon?
Vielleicht bekommt die App Windows-Botschaften von ausserhalb.

Habe jetzt eine Weile mit dem Process Monitor draufgeschaut. Die Anwendung macht im minimierten Zustand rein gar nichts. Zumindest nichts, was sich dort anzeigen ließe.

Und ich habe natürlich keinen Idle-Loop, der auf eine Eingabe wartet, sonst wüsste ich ja, wo das Problem zu suchen ist. Falls irgendsowas in einer Delphi-Unit drin ist, wäre ja genau das herauszufinden.

[TiGü]

Glaskugel sagt: Du hast einen externen Thread, der mit Sleep(...) in Dauerschleife läuft und irgendwas pollt/pollen soll.