Supported Windows DNS Client instrumentation for caller-to-result correlation

Question

Supported Windows DNS Client instrumentation for caller-to-result correlation

落合卓也 0

On supported Windows 11 releases, is there a documented extension point or provider contract that lets a diagnostic tool correlate a DNS request from an existing desktop process with the result returned through the shared Windows DNS Client resolver?

Is there a documented request key available at both the original caller and the resolver, including concurrent requests for the same name, cache hits, errors, and cancellation?

Can the provider restrict event generation to selected process instances before preparing or emitting events, including the first event from a helper process that starts after monitoring is enabled?

If supported, which Windows builds, provider GUIDs, event IDs and versions, and APIs document these guarantees? If any part is outside the supported contract, which part?

This is a general question about documented Windows APIs and provider behavior. No logs or environment data are attached.

0 comments

1 answer

Your answer

Answer 1

Hi @落合卓也 ,

Based on the public documentation, Windows does not document an extension point or a Microsoft-Windows-DNS-Client provider contract that exposes a request key shared by the original caller and the shared resolver. Event IDs, versions, payload fields, and correlation guarantees for concurrent requests, cache hits, errors, and cancellation are not part of a documented contract that I could find.

On the caller side, the documented surface is the DnsQueryEx function and the newer DnsQueryRaw function. Their context, result, and cancel handle belong to the calling process. The DNS_QUERY_RAW_RESULT structure can indicate DNS_PROTOCOL_NO_WIRE when no query was sent on the wire, but only to the caller. For cancellation, the GetAddrInfoExCancel documentation notes that some underlying operations are synchronous and keep running after cancellation, so caller side cancellation does not guarantee the resolver work stops.

As for process scoping, the EVENT_FILTER_DESCRIPTOR documentation states that EVENT_FILTER_TYPE_PID enables the provider only in processes running when EnableTraceEx2 is called, and a process that starts later is not automatically enabled. A PID filter therefore cannot cover the first event from a helper process started after monitoring begins. My understanding is also that a filter on the caller's PID would not match events written by the resolver service process, though this is my reading rather than a documented statement. To identify process instances, the Process Start Key option in ENABLE_TRACE_PARAMETERS adds a key that is unique within the boot session. If you want to see which event IDs and versions a given build defines, the TdhEnumerateManifestProviderEvents function lists them from the installed manifest, but that reflects the current build rather than a stability commitment.

I understand this may not be the definitive answer you were hoping for; however, this is as far as I can help within the scope of forum support. If you need a deeper or authoritative confirmation, for example for specific Windows builds or about future support, I would recommend reaching out to Windows Developer Support, where engineers can look into the implementation in more depth.

I hope this helps clarify the available documentation. If you found my explanation above was truly helpful or informative to you, I would greatly appreciate it if you could follow this guidance so others with the same issue could benefit as well.

Thank you.