8
votes

I am using the following C# code in a Windows Service (which runs as NT_AUTHORITY\SYSTEM) to create an event handler for receiving process creation events (using WMI and WQL):

string queryString = "SELECT * FROM Win32_ProcessStartTrace";
ManagementEventWatcher watcher = new ManagementEventWatcher(new WqlEventQuery(queryString));
watcher.EventArrived += new EventArrivedEventHandler(ProcessStartEvent);
watcher.Start();

In ProcessStartEvent:

int processId = int.Parse(e.NewEvent.Properties["ProcessId"].Value.ToString());
Process proc = Process.GetProcessById(processId);

Out("Received process: " + proc.ProcessName);

The problem I'm having is that (for some strange reason) not every process start is captured and reported by the program. If I start about 6 processes simultaneously, one may not show up in the output.

I've tried to do some research on capturing process creation events using WMI, but there is limited information available. I've seen that it is also possible to capture process starts using something similar to:

SELECT TargetInstance
FROM __InstanceCreationEvent
WITHIN  2
WHERE TargetInstance ISA 'Win32_Process'

(As seen in this Stack Overflow answer)

Are there any major differences between using __InstanceCreationEvent and Win32_ProcessStartTrace? Could this be the cause of my problems?

Is there an explanation as to why I'm not receiving events for all process starts? Is there something more obvious that I'm doing wrong here?

2
@Dimi I would say this is quite a different question, since this focuses on why some events seemingly vanish while others are caught even when using the supposedly "correct" method for catching process start events. - Xenon
Late to the part, but I'd like to add that those extrinsic events (Win32_ProcessStartTrace, Win32_ProcessStopTrace) requires administrator rights, while the same is not needed for the intrinsic ones (__InstanceCreationEvent, __InstanceDeletionEvent). You can try this from a Powershell console already - superjos

2 Answers

8
votes

Both methods are valid but works in differents ways.

When you uses the __InstanceCreationEvent WMI class you are using a intrinsic event which means which you are monitoring changes in the standard WMI data model (this works like a trigger in a table).

When you uses the Win32_ProcessStartTrace you are using a Extrinsic event that means you are using a specialized event class made for a specific task in this case monitor the process creation.

Now back to your issue, the best way to avoid the "lost" of some events is creating a permanent event consumer.

4
votes

I've found when you get an event that a process has started - pass that event into a seperate thread with for instance boost thread you can pass the process ID to a new thread.

This means the WMI COM doesn't get in a tangle and stop itself working.

see http://sourceforge.net/p/processhistory/code/HEAD/tree/trunk/PHLogger/ and look for a revision with COM_WMI_Consumer/

for some working C++ code.