0

I've been writing a program in C# to scavenge information out of WMI as a project (I know many great tools out there exist already, but this is both for learning and custom tailored to an environment I manage), and I've come across a few oddities. Currently tripping me up is the following snippet below:

'using System.Management;

ManagementClass managementClass = new ManagementClass(new ManagementPath(@"\\" + pHostName + @"\root\" + pNameSpace));

EnumerationOptions enumOptions = new EnumerationOptions();
enumOptions.EnumerateDeep = false;

foreach(ManagementObject wmiClass in managementClass.GetSubclasses())
{
    Console.WriteLine(wmiClass["__Class"].ToString());
}'

Given the definition of System.Management.ManagementClass under both the MSDN documentation and the VS Documentation, which I'll paraphrase pretty heavily to say it represents a CIM class, and the definition for the GetSubclasses() method which returns a collection of all subclasses under a class (under a class being the key phrase there), the only logical conclusion I can make as to why this works is that a Namespace in WMI is actually an instance of a class, which sounds incredibly wrong.

Are Namespaces actually instances of classes in WMI? If not, does anyone know why using a ManagementClass on a namespace allows class scavenging? The language used is really confusing me.

EDIT: Going to answer the question here. Hans Passant below pointed out that IWBEMPath is the cause of the issue, and that Namespaces are treated as both directories and Classes by ManagementPath due to IWbemPath, which is used to instantiate a new instance of ManagementClass. Thanks Hans!

Christopher D Albert
  • 57
  • 1
  • 10
  • Can you tell us what you expected to happen and what actually happened? What is your console output? I suspect I know the source of your issue. – Gusdor Sep 03 '15 at 13:38
  • 1
    The .NET object model is a bit screwy, caused by the way the underlying COM interfaces work. IWbemPath is the troublemaker, it can represent both a namespace and a class. Probably the best way to mentally model it is like the way a disk drive is organized. A path on a file system can represent both a directory and a file. Compare to the System.IO.FileSystemInfo class. You distinguish the two with ManagementPath.IsClass – Hans Passant Sep 03 '15 at 13:47
  • I honestly expected it to fail. The console output is all of the classes under the chosen namespace. The output is as you would expect from a class query under a namespace, so I'll just paste a few sample ones here: __SystemClass __SystemSecurity CIM_ManagedSystemElement ....etc – Christopher D Albert Sep 03 '15 at 13:53
  • Thanks @HansPassant, that makes more sense. That explains why ManagementClass treats a namespace the way it does too, and why GetSubclasses works, because all classes under it are treated as children. I thought I was crazy for thinking that – Christopher D Albert Sep 03 '15 at 13:58
  • See also: [ManagementObject reference source](http://referencesource.microsoft.com/#System.Management/managementclass.cs,fb931422ed5d0cab) (The link should be to the `GetSubclasses()` method) – theB Sep 03 '15 at 14:09

0 Answers0