EventTraceLogger ETW

[himitsu]

Ich bin ja seit 'ner Weile dabei mit dieser API zu spielen.
-> das Hocheffizienz-Logging-System von Windows (arbeitet intern auf Basis von WMI)
https://learn.microsoft.com/en-us/wi...tracing-portal

Alleine der NT Kernel Logger liefert hier locker 100.000 bis über 'ne Mio Events pro Sekunde.
(ich bin überrascht, daß und wie schnell man 200 Mio Zeilen schrittweise in ein normals TMemo rein bekommt)


Was damit möglich ist, sieht man am Taskmanager und besonders am Ressourcenmonitor.
Der ProcessExplorer wäre auch ein Beispiel, auch wenn Dieser mit Filtertreibern arbeitet, aber großteils mit den Ergebnissen des Eventtracing vergleichbar.
(OK, bezüglich TCP/UDP, Registry- und Festplatten-Zugriff fehlen im Eventlog die geschriebenen/gelesenen Daten, da nur Name und Position geloggt wird, mit teilweise optional zuschaltbarem Stacktrace)



Gemein ist, dass große Teile der Dokumentation des Herstellers einfach falsch sind (falsche Typen ... meistens als 32 Bit-Typ beschrieben (z.B. UINT32), aber oftmals immer 64 Bit (POINTER/HANDLE), auch wenn man für Win32 kompiliert),
auch sind die Versionen/Nummern oft veraltet oder grundsätzliche falsch beschrieben und viele Operationen/Opcodes fehlen in der Doku.
-> Beispiel siehe Demoanwendung

Ich arbeite aktuell meistens mit Win32, da im Delphi 11.2 für Win64 das Debuggen eine unmögliche Quall ist.


"The Worst API Ever Made"
https://caseymuratori.com/blog_0025
Gut, ein Teil bezüglich seiner Analyse stimmt nicht, aber sonst kann ich ihn gut verstehen.

"32 event types should be enough for everyone" ... Bit 31 ist undokumentiert, aber es schaltet (wohl) eine Liste zu, wo mehr rein passten würde. (32 Bit ListenRecords = 4 Milliarden anstatt BitMask)
Und die 32 "Flags" beziehen sich auch immer nur auf den jeweiligen Logger, wo man sich registriert. Andere Logger nutzen es nicht, oder haben eine eigene Definition dieser Flags.





Aktuell nur als Realtime-Logger registrieren und mitlesen,
gespeicherte Logs lesen würde aber auch gehen, bzw. nur das Logschreiben (in Datei) starten und später auslesen.

Und erstmal für den "NT Kernel Logger" und dessen Möglichkeiten
https://learn.microsoft.com/en-us/wi...nt-systemtrace

Beispiel einiger Möglichkeiten bezüglich .NET
https://youtu.be/qGEeZZBwVp4?t=640
https://github.com/microsoft/perfview
Neben dem NT Kernel Logger gibt es noch viel mehr, wie z.B. Einen für's .NET-Framework und dessen MethodenTracing und Speichermanagement/GarbageCollector.



Selbst ins Log schreiben will ich aber auch irgendwann können und hoffe Emba kopiert es teilweise bei "sich" rein.
-> TMonitor und Thread.Synchronize bzw. Queue (default aus, aber aktivierbar)

Denn TCriticalSection schreibt da rein, aber System.TMonitor nicht.
Es wäre jedenfalls bestimmt praktisch, wenn man, ähnlich dem Video, bezüglich Sperren eine Analyse starten könnte, um z.B. Deadlocks (rück)zuverfolgen.




Im Anhang ein erstes BasisLogging, mit auskommentieren halbfertigen Auswertungen (Records in einzelne Werte zerlegen und für Namensauflösungen verknüpfen)
Also ich schreibe die Rohdaten von ALLEM mit und versuche dafür den ProviderName und OpcodeName aufzulösen, in Bezug der ProviderID + Version.
Ist wichtig, um das versionsabhängige jeweilige DatenFormat bestimmen zu können.
Wo es nicht klappt, dann steht anstatt "Name"
* "123~Name" für bekannten/gleichen Opcode (mir bekannt, bzw. laut Doku), aber nicht in der empfangen Version enthalten
* "Opcode-C81-V02-11D0FE053D6FA8D3" für unbekannten Opcode in allen bekannten Versionen der jeweiligen ProviderId
* "Version-V02-11D14A3E68FDD900" für unbekannte Verion
* "Provider-123456789ABCDEF0" für unbekannten Provider
* ...

Vorhin noch schnell eine Checklisbox eingebaut, zur Einschränkung dieses Loggers.
* Programm sollte als Admin laufen
* für "sample base profiling" muß wohl noch irgendeine Berechtigung aktiviert/abgerufen werden ... ausführen als Admin reicht nicht aus
* unten der Button für eine Schnellauswahl mehrmals Links, bzw. einmal mit Rechts knuffen

Headerübersetzung wird, wenn sie halbwegs "stimmig" ist, freigeben (wie gesagt, aktuell sind zuviele Fehler drin, obwohl ich schon Vieles durch Selbstversuche und Abgleich mit anderen Dokus/Demos berichtigt hab)




Pervers wird es, wenn man die "page faults" aktiviert ... einige Programme (Firefox, BDS) bestehen scheinbar nur aus heimlichen/abgefangenen (quasi try-except) AccessViolations.
https://www.digiater.nl/openvms/doc/...91pro_006.html -> 7.2.1.1 Hard and Soft Page Faults

[himitsu]

DbgPrint lässt sich zwar ohne Fehlermeldung im Logger aktivieren (auch wenn es in der offiziellen Doku nicht drin steht, aber in der MOF finde ich es und Andere haben es auch in Systemdateien nachgewiesen),
aber es wird nichts empfangen.

Weder stundenlang von irgendeinem Programm im Windows, noch wenn ich es selber aufrufe.

Delphi-Quellcode:

function DbgPrint(Format: PAnsiChar): ULONG; cdecl; varargs;
  external 'NtDll.dll' name 'DbgPrint';

function DbgPrintEx(ComponentId, Level: ULONG; Format: PAnsiChar): ULONG; cdecl; varargs;
  external 'NtDll.dll' name 'DbgPrintEx';

procedure TForm13.FormCreate(Sender: TObject);
begin
  DbgPrint('%i %X', 12345, 12345);
  DbgPrintEx(77{DPFLTR_IHVDRIVER_ID}, $1 shl 0{DPFLTR_ERROR_LEVEL}, '%i %X', 12345, 12345);
  OutputDebugString('abcde');
end;

Nja, vielleicht funktioniert es nur aus einem Treiber heraus
und außerdem lese ich öffters, dass die API nichts sendet, wenn ID/Level nicht stimmen, bzw. nicht aktiviert wurden. (oder irdendwie so)
DbgPrint

Zitat:

The DbgPrint routine sends a message to the kernel debugger.

In Windows Vista and later versions of Windows, DbgPrint sends a message only when the conditions that you specify apply (see the Remarks section for information).

MOF: siehe *.mof in C:\Windows
oder C:\Program Files (x86)\Windows Kits (vom Delphi)

bzw. siehe auch C:\ -> Defender, .NET Framework, Powershell, ...