The rest of the post is a simple walkthrough of using the API and collecting the events in Procmon.
- Step 1 – Compile solution. John shares a source code. Download it here. It is Visual Studio 2008 project. It’s possible to compile it with Visual Studio 2010. I used VS 2010 RC. The result is 3 binaries:
- ProcMonDebugOutputx64.dll – native code dll that reports events to Procmon on 64 bit machine for 64 bit processes.
- ProcMonDebugOutputx86.dll - native code dll that reports events to Procmon on 32/64 bit machine for 32 bit processes.
- Sysinternals.Debug.dll – managed code dll that calls either of the above depending on the process that runs it.
- Step 2 – Report events from your app. When using it from managed code use System.Diagnostics.Trace.WriteLine(“your message to procmon”). I use it massively when inspecting performance issues. I usually collect the messages with another free xcopy tool from sysinternals – DebugView. Remember to put the three dll’s created in Step 1 into your bin folder.
- Step 3 – Configure trace listener in config file. John implemented tracelistener in his Sysinternals.Debug.dll. Following is the configuration needed to enable it collecting events from the application and passing them to Procmon:
<?xml version="1.0" encoding="utf-8" ?>
<add name="procmon" type="Sysinternals.Debug.ProcessMonitorTraceListener, Sysinternals.Debug"></add>
- Step 4 – Test the solution. Test the solution by running the Procmon and then your application. Make sure “Show Profiling Events” button is pressed on the toolbar. For test purposes I have implemented a code that issues web requests to microsoft.com and prints out the response. Note, the code is for demo only – it’s not optimized for performance and reliability. Here it is:
static void Main(string args)
WebRequest request = WebRequest.Create(http://www.microsoft.com);
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
Stream dataStream = response.GetResponseStream();
StreamReader reader = new StreamReader(dataStream);
string responseFromServer = reader.ReadToEnd();
Following is the output of the execution of this code as it shows in new and improved Procmon – you can see that both application and system events live in harmony and you can see the latency each one of them contributes:
Thank you, Mark and John.