Dokumentierter ETW-Nachweis für Named-Pipe-Handle, Endpoint und I/O-Completion unter Windows 11 x64 — begrenzte Frage zu FileIo / OpEnd

Jann Heck 20 Reputation points
2026-10-23T08:45:24.11+00:00

Guten Tag,

für eine isolierte Windows-QA-Umgebung prüfen wir einen begrenzten Nachweisweg für die Named-Pipe-Kommunikation genau festgelegter Testprozesse. Wir möchten keine Vollüberwachung des Betriebssystems und keine undokumentierten Hooks, sondern die tatsächlich unterstützten Aussagen öffentlicher Windows-Ereignisquellen abgrenzen. Plattformstand: - Vorhandener Host laut lokaler Bestandsaufnahme: Windows 11 Pro x64, Buildfamilie 26200. Die genaue Updaterevision ist hier noch nicht gebunden. - Dedizierter QA-Gast: lediglich geplant, noch nicht eingerichtet/qualifiziert. - Exakter Gastbuild, Updaterevision und Windows-SDK-/WDK-Version: noch nicht gebunden. - Die Anfrage betrifft daher zunächst den dokumentierten Mechanismus und dessen Versionsgrenzen. Wir bitten ausdrücklich nicht um eine Aussage über eine bereits qualifizierte Installation. Falls eine genaue Buildbindung für einzelne Antworten notwendig ist, benennen Sie bitte diese Voraussetzung und die unterstützten Versionen. Aus den öffentlichen Dokumentationen verstehen wir derzeit: FileIo_ReadWrite liefert unter anderem FileObject, FileKey, IrpPtr, TTID und IoSize. IoSize bezeichnet die angeforderte, nicht automatisch die tatsächlich übertragene Bytezahl. FileIo_OpEnd kann gesondert aktiviert werden, erlaubt die Korrelation über IrpPtr und enthält NtStatus sowie operationsabhängiges ExtraInfo. Das dortige Beispiel für ExtraInfo nennt tatsächlich gelesene Bytes. FileIo_SimpleOp unterscheidet Cleanup des letzten Handles und Freigabe des Dateiobjekts. Daraus leiten wir gerade keinen vollständigen Beleg jedes einzelnen ursprünglichen Win32-Handles oder jedes CloseHandle-Aufrufs ab. Bitte klären Sie für benannte und gegebenenfalls anonyme Pipes: 1. HANDLE / OBJEKT / ENDPOINT Welche dokumentierte Provider-/Event-/Schema-Kombination ordnet ein konkretes prozesslokales ursprüngliches Pipehandle einschließlich seiner Lebensdauer dem FileObject, einer konkreten Pipeinstanz und der Server-/Clientseite zu? Wie sind gegebenenfalls vererbte/duplizierte Handles und Wiederverwendung der Identifikatoren zu behandeln? Wir setzen nicht voraus, dass FileObject selbst der User-Mode-HANDLE ist. Falls diese Relation mit den öffentlichen Ereignissen nicht unterstützt wird, bitten wir um die ausdrückliche Angabe der fehlenden Relation statt einer bloßen Empfehlung, zusätzlich File-I/O aufzuzeichnen. 2. REQUEST / COMPLETION / TATSÄCHLICHE MENGE Welche Ereignisse und Felder tragen bei diesen Pipes die Zuordnung von Read/Write-Anforderung zu endgültigem Abschlussstatus und tatsächlich gelesener bzw. geschriebener Bytezahl? Bitte unterscheiden Sie angeforderte Länge, STATUS_PENDING bzw. asynchronen Zwischenzustand, endgültige Completion, Teilübertragung, Abbruch/Cancel, Fehler und erneuten API-Aufruf/Retry. Gilt die ExtraInfo-Semantik dokumentiert auch für Pipe-Writes und alle hierfür relevanten Abschlussarten? Welche Regeln begrenzen IRP-Korrelation und Reuse? 3. OPERATIONSABDECKUNG UND AUSSAGEGRENZEN Welche unserer Klassen Create/Open, Connect, Read, Write, Flush, Disconnect, Cancel und einzelnes Close sind durch welche dokumentierten Ereignisse abgedeckt? Bitte geben Sie für jede nicht abgedeckte Klasse ausdrücklich „nicht durch diese Quelle unterstützt“ an. Wir behaupten keine Eins-zu-eins-Beziehung zwischen Win32-Aufrufen und Kernel-Requests und möchten diese Beziehung nicht erraten. Welche zulässigen I/O-Pfade erzeugen für diese Quellen keine entsprechenden Events? 4. START / LOSS / DEKODIERUNG Welche Provider, GUIDs, Eventversionen/Keywords, Aktivierungsreihenfolge, Privilegien und Decoder-/SDK-Voraussetzungen sind für die genannte Zuordnung nötig? Welche Start- und Abschlussbedingungen sowie Verlustinformationen sind relevant? Wir interpretieren Nullwerte bei ETW-Verlustzählern nicht als Beweis, dass jede gewünschte Ereignisklasse vom Provider überhaupt erzeugt wurde. Bitte antworten Sie möglichst in dieser Form: Aussage | Provider/Event/Version/Feld | Zuordnungsregel | unterstützte Builds | Einschränkung/fehlende Aussage | offizielle Dokumentationsreferenz. Ein klarer negativer Bescheid für einzelne Relationen ist für uns ebenso hilfreich wie ein positiver: Wir müssen unterscheiden können, ob ein vollständiger Nachweis innerhalb des begrenzten Profils möglich ist, eine zusätzliche unterstützte Quelle benötigt wird oder die behauptete Aussage nicht von dieser Telemetrie getragen wird. ALPC, die vollständige Beobachtung beliebiger Anwendungen und eine Freigabe unserer QA-Umgebung sind ausdrücklich nicht Gegenstand dieser Anfrage. Auch eine positive Antwort würde noch durch gesonderte begrenzte Kontrollen an einer exakt gebundenen Plattform überprüft werden.

Vielen Dank.

Windows development | Windows API - Win32
0 comments
Answer accepted by question author
Taki Ly (WICLOUD CORPORATION) 5,880 Reputation points Microsoft External Staff Moderator
2026-10-23T10:43:57.8266667+00:00

Hallo @Jann Heck ,

vielen Dank für die präzise Abgrenzung. Ich habe die öffentlich verfügbare Microsoft-Dokumentation geprüft und stütze meine Antwort ausschließlich darauf. Wo ich keine dokumentierte Aussage finden konnte, kennzeichne ich das ausdrücklich. Die FileIo-Klassen fand ich nur generisch für File-I/O dokumentiert (Mindestversion Windows Vista, EventVersion(2)). Eine pipe-spezifische Semantik oder eine Buildbindung für 26200 habe ich nicht gefunden. Anonyme Pipes sind laut Anonymous Pipe Operations als Named Pipes mit eindeutigem Namen implementiert, daher gilt für sie meines Erachtens dasselbe.

1. Handle / Objekt / Endpoint

  • Unterstützt: FileObject (in FileIo_Create, FileIo_ReadWrite, FileIo_SimpleOp und FileIo_Info) korreliert Operationen derselben Dateiobjektinstanz zwischen Create und Close. Den Namen erhalten Sie, indem Sie FileKey mit dem Feld FileObject in FileIo_Name abgleichen.
  • Folgendes konnte ich in dieser Quelle nicht finden:
    • die Zuordnung zwischen prozesslokalem HANDLE und FileObject; kein FileIo-Ereignis enthält einen HANDLE-Wert,
    • die Pipeinstanz und die Server-/Clientseite,
    • einzelne CloseHandle-Aufrufe (laut FileIo_SimpleOp: Cleanup = letztes Handle, Close = Freigabe des Objekts),
    • vererbte Handles,
    • Regeln zur Wiederverwendung von FileObject.
  • Als separate Quelle auf Handle-Ebene habe ich Security Auditing 4656, 4658 und 4690 gefunden, mit HandleId, ProcessId und Duplizierung (Voraussetzungen: SACL und Audit Handle Manipulation). Diese Ereignisse haben jedoch kein FileObject-Feld, und eine dokumentierte Verknüpfung zu ETW FileIo konnte ich nicht finden.

2. Request / Completion / Menge

  • Unterstützt: IoSize in FileIo_ReadWrite ist die angeforderte Länge. Über IrpPtr lässt sich das Ereignis mit FileIo_OpEnd korrelieren, das NtStatus enthält. ExtraInfo = tatsächlich gelesene Bytes, allerdings nur als Beispiel für Read dokumentiert.
  • Keine dokumentierte Aussage habe ich gefunden zu:
    • ExtraInfo bei Writes,
    • STATUS_PENDING bzw. Zwischenzuständen,
    • Teilübertragung, Cancel und Retry,
    • der Wiederverwendung von IrpPtr.

3. Operationsabdeckung

  • Abgedeckt (generisch): Create/Open (64), Read (67), Write (68), Flush (73; die Semantik ist als „flushed to disk“ beschrieben, nicht für Pipes).
  • Nicht durch diese Quelle unterstützt: Connect, Disconnect, Cancel, einzelnes Close.
    • FSControl (75) existiert laut FileIo_Info, aber eine dokumentierte Abbildung auf ConnectNamedPipe/DisconnectNamedPipe habe ich nicht gefunden.
  • Ereignislose Pfade: Laut IRPs Are Different From Fast I/O versucht der I/O-Manager bei synchronem I/O zuerst Fast I/O. Ist das erfolgreich, wird kein IRP erzeugt. Ob dabei FileIo-Ereignisse entstehen und ob NPFS Fast I/O nutzt, ist meines Wissens nicht dokumentiert.

4. Start / Loss / Dekodierung

  • Laut EVENT_TRACE_PROPERTIES gilt:
    • FILE_IO_INIT (0x04000000) aktiviert Create/ReadWrite/SimpleOp/Info,
    • FILE_IO (0x02000000) aktiviert nur OpEnd,
    • DISK_FILE_IO (0x200, FileIo_Name) erfordert zusätzlich DISK_IO.
    Klassen-GUID FileIo: {90cbdc39-4a3e-11d1-84f4-0000f80464e3}.
  • Ab Windows 10 SDK 20348 ist laut System Providers alternativ SystemIoProviderGuid {3d5c43e3-0f1c-4202-b817-174c0070dc79} möglich. Die dortige Keyword-Zuordnung für FILE_IO_INIT halte ich jedoch für unklar dokumentiert.
  • Erforderliche Rechte laut Controlling Event Tracing Sessions: Administrator, Performance Log Users oder LocalSystem/LocalService/NetworkService. Für Ereignisversionen jenseits von v2 habe ich kein öffentliches Schema gefunden.
  • Verlustinformationen: EventsLost/BuffersLost in EventTrace_Header und RT_LostEvent. Diese Zähler sagen nichts darüber aus, ob eine Ereignisklasse überhaupt erzeugt wurde. Ihre Interpretation halte ich daher für korrekt.

Fazit: Nach meiner Prüfung ist ein vollständiger Nachweis innerhalb des begrenzten ETW-Profils nicht möglich. Security Auditing ergänzt die Handle-Ebene nur teilweise und ohne dokumentierte Verknüpfung zu FileObject. Für buildgebundene Aussagen oder NPFS-Interna empfehle ich Ihnen einen Microsoft-Support-Fall.

Ich hoffe, dies hilft Ihnen bei der Beantwortung Ihrer Fragen. Wenn Sie meine Antwort hilfreich oder informativ fanden, würde ich mich sehr freuen, wenn Sie der Anleitung hier folgen, damit auch andere mit einem ähnlichen Problem davon profitieren können.

Vielen Dank.

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jann Heck 20 Reputation points
    2026-10-23T17:10:16.2933333+00:00

    Vielen Dank für die sorgfältige und differenzierte Prüfung. Die Abgrenzung zwischen den dokumentierten Teilinformationen und den nicht belegten Handle-, Endpunkt- und Abschlussbeziehungen hilft uns sehr. Wir halten damit fest, dass die untersuchten öffentlichen Ereignisquellen unseren vollständigen Nachweis derzeit nicht tragen. Daraus leiten wir weder eine allgemeine Unmöglichkeit unter Windows noch eine Aussage über eine bereits qualifizierte Installation ab. Einen gegebenenfalls erforderlichen Supportfall würden wir erst mit einer konkret gebundenen Plattform und einer verbleibenden, entscheidungsrelevanten Frage eröffnen.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.