WMI process start event - not all detected start processes

Question

I use the following C # code in a Windows service (which works like NT_AUTHORITY\SYSTEM ) to create an event handler to receive 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 am facing is that (for some strange reason) not every startup process is fixed and reported by the program. If I start about 6 processes at the same time, the output cannot be displayed.

I tried to do some research on capturing process creation events using WMI, but there is limited information. I saw that you can also start the process using something similar to:

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

(As seen from this stack overflow answer )

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

Is there any explanation why I am not getting events for the all process? Is there something more obvious that I'm doing wrong here?

Answer 1

Both methods are valid, but work differently.

When you use the __InstanceCreationEvent WMI class, you use the intrinsic event, which means that you control changes in the standard WMI data model (this works like a trigger in a table).

When you use Win32_ProcessStartTrace , you are using the Extrinsic event, which means that you are using the specialized event class created for a specific task in this case to track the creation of the process.

Now back to your problem, the best way to avoid some of the “lost” events is to create a permanent event consumer .

Answer 2

I found that when you receive an event in which the process is running, pass this event to a separate thread, for example, to speed up the thread, which you can pass to the process identifier in a new thread.

This means that WMI COM does not get confused and stops working.

see http://sourceforge.net/p/processhistory/code/HEAD/tree/trunk/PHLogger/COM_WMI_Consumer/

for some working C ++ code.