Question about WMI architecture

This is question more about windows internals that driver development itself.

From what I learnt myself it looks like that(more or less):

  1. Process calls CoCreateInstance to create WMI instance
  2. Process loads fastprox.dll
  3. svchost.exe looks for providers and loads them into newly created WMIPrvSE.exe process (like cimwin32.dll)
  4. I execute some WMI query
  5. fastprox.dll uses ALPC to query WMIPrvSE.exe it gets response from cimwin32.dll and passes it back to process that queried WMI

Is that more or less correct? Could someone give me more in-deep overview of what happens under the hood?

I’m interested more how it spawns processes and how it looks for providers, not how it implements them (because I already know that).

How internally WmiPrvSE.exe is spawned and what’s the role of WmiApSrv.exe and how exactly communication between each processes is managed and how WmiPrvSE.exe knows to which process it should send.

xxxxx@gmx.com wrote:

This is question more about windows internals that driver development itself.

From what I learnt myself it looks like that(more or less):

  1. Process calls CoCreateInstance to create WMI instance
  2. Process loads fastprox.dll
  3. svchost.exe looks for providers and loads them into newly created WMIPrvSE.exe process (like cimwin32.dll)
  4. I execute some WMI query
  5. fastprox.dll uses ALPC to query WMIPrvSE.exe it gets response from cimwin32.dll and passes it back to process that queried WMI

Is that more or less correct? Could someone give me more in-deep overview of what happens under the hood?

This is all very standard out-of-process COM stuff, doing RPC to proxy
between the processes.  There’s nothing terribly special about WMI in
this respect.  One of the good COM texts, like Don Box’s “Essential COM”
or Dale Rogerson’s “Inside COM” might be a good place to start.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.