There is one last WMI accelerator to look at - [WMI] - which is an accelerator for System.Management.ManagementObject. This is the same object type that Get-WMIObject returns. [WMI] gets an object representing an existing WMI object
If we start with Get-WmiObject
$w1 = Get-WmiObject -Class Win32_Process -Filter "Name = 'notepad.exe'"
$w1 | get-member
If we try to emulate this with [WMI] we start to run into some issues. The only path that I could get to work was
$w2 = [WMI]'root\cimv2:Win32_Process.Handle="4112"'
$w2 | get-member
I tried name, description and other candidates but none seemed to work. Only thing I can think of is that to create that PowerShell is constraining the object creation.
Alternatively the object could be created like this
$y = [WMI]""
$y.psbase.Path = '\\PCRS2\root\cimv2:Win32_Process.Handle="4112"'
Comparing the results of these three techniques we get
Compare-Object -ReferenceObject $w1 -DifferenceObject $w2
Compare-Object -ReferenceObject $w1 -DifferenceObject $y
Both of which indicate the objects are the same.
Looking at creating this with .NET
$z = New-Object -TypeName System.Management.ManagementObject -ArgumentList '\\.\root\cimv2:Win32_Process.Handle="4112"'
$z | Get-Member
Compare-Object -ReferenceObject $w1 -DifferenceObject $z
Again the same object is created and I could only get it to build when I use the handle.
The object creation works when I do
$t = Get-WmiObject -Class Win32_process -Filter 'name="notepad.exe"'
As we need to know the path before we can use [WMI] it may be easier to use get-WmiObject instead. I'd be interested in hearing other peoples take on [WMI] and how they are using it