WinHttp Tracing

The WinHttp stack has ETW tracing embedded into it to a profound level. Given the importance of ETW subsystem, this seems unlikely to change.

However both the documentation and the MS provided tools do not appear to be being regularly updated - the fact that the architecture document refers to Window 7 as the shiny new OS is the hint.

The document is is a walk through of one small analysis session. It may not be the most effective way of proceeding and the more informed reader is encouraged to extend this

As per this page. Collect the traces using netsh

c:\> netsh trace start scenario=internetclient

Trace configuration:
-------------------------------------------------------------------
Status:             Running
Trace File:         C:\Users\rdw\AppData\Local\Temp\NetTraces\NetTrace.etl
Append:             Off
Circular:           On
Max Size:           512 MB
Report:             Off

And as per this page use the (archived) Network Monitor to inspect them.

The monitor file will be very “busy” and it will be useful to know the PID of the process issuing the WinHttp requests

Start Network Monitor
One off turn on the “Windows” Parsers
Hit Open Capture and browse to, then open the etl file
We want to find the PID in the view. So look in the Network Conversations and find an WinHttp activity
Then check that the “UT Process Name” matches the PID and add it as a filter

Now Apply the filter

At this stage you have all the Web client actions that your process issued . Browse through the Activities in the left hand column - many of them will be filtered out (because they are not to do with the Remoting client).

In my experience most of the interesting stuff happens in the WebIO actvities

(for some definition of “interesting”).

As an alternative

Use WireShark (this will work for Curl as well of course). This comment gives details of how to configure Jetty to degrade its TLS connection to a level that WireShark will be able to sniff and decode the packets.