Asynchronous WMI Queries: Stay Away From Them

So, it turns out that I have a WMI category on my blog. During the last couple of years I almost forgot about it, but WMI got a chance to wrap its poisonous tentacles around me again yesterday. Here’s another story.

WMI is known for requiring lots of attention to security. To establish a WMI connection to a remote machine, you need to muck around with registry settings, DCOM configuration, group policy details, and other infernal things which we developers like to defer to someone else. But at least you know that once a machine has been configured properly to give you access through WMI, you can then access it from any other machine. Right? Right?

Not so much. WMI has a concept of asynchronous queries, which are notably used for receiving event notifications. For example, the following code registers for an event notification whenever a process is created on my desktop machine:

ManagementScope scope = new ManagementScope(@"\\sasha-desktop\root\cimv2");
WqlEventQuery query = new WqlEventQuery(
                             "SELECT * FROM Win32_ProcessStartTrace");
ManagementEventWatcher watcher = new ManagementEventWatcher(scope, query);
watcher.EventArrived += (o, e) => ...; //TODO: process the event
watcher.Start();

Indeed, this thing works just fine if you point it to a local machine; but it fails when you call the Start method when you connect it to a remote machine. You could now strip the remote machine bare and have it expose its very innate networking guts to the entire Internet, and it still wouldn’t help you establish the connection. Interesting.

When troubleshooting this nasty bug, I looked up a VBScript sample that receives new process creation events on another machine. Here it is:

Set wmi = GetObject("winmgmts:\\sasha-desktop\root\cimv2")
Set query = wmi.ExecNotificationQuery _       
    ("SELECT * FROM Win32_ProcessStartTrace'")
Set process = query.NextEvent

VBScript and all, it worked just fine. I started to suspect something smelly in the kingdom of .NET, so I rewrote the VBScript sample in C#, using the long-forgotten Microsoft.VisualBasic.Interaction class:

dynamic wmi = Microsoft.VisualBasic.Interaction.GetObject(
                   "winmgmts:\\sasha-desktop\root\cimv2");
dynamic query = wmi.ExecNotificationQuery(
                   "SELECT * FROM Win32_ProcessStartTrace");
dynamic evt = query.NextEvent;

This, too, worked just fine – although it’s not much a surprise, as it’s pretty much equivalent to the VBScript code at this time. Still interesting.

This is when it hit me – the asynchronous nature of the ManagementEventWatcher.EventArrived event relies on an asynchronous WMI query, which requires a reverse connection to the client machine! This is configuration inferno, x2, on the client machine now, what with the DCOM security settings and sacrifices to the gods of group policy.

Unless, of course, we give away the asynchrony and rely on the ManagementEventWatcher.WaitForNextEvent method. It’s synchronous. It burns a thread that has to sit idly by and wait while its siblings execute useful work. But it doesn’t establish a reverse DCOM connection to the caller. At least that.