• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1242
  • Last Modified:

Propertly detecting memory slots and memory with WMI?

Our Win32 app has successfully detected memory slots and associated memory on machines in the past by using SMBios calls. But we recently moved to using WMI calls.

However, running on newer Dell machines (Dell GX280 with Windows 2003 sp1 for example) are reporting odd,incorrect results.

The machine has 4 memory slots, with 2 containing memory chips, but our results are showing all slots containing memory.

To fetch the slot configuration we first query: select * from win32_memorydevices.
Then for each row returned, we fetch the ASSOCIATORS of the row where the class is Win32_physicalmemory:

CString strQuery = "ASSOCIATORS OF {Win32_MemoryDevice.DeviceID=\"";
                                    strQuery += sMemoryDeviceID;
                                    strQuery += "\"} WHERE ResultClass = Win32_PhysicalMemory";

There must be a problem in our queries. Is these the proper queries to execute to determine the number of slots, and then whether or not each slot has memory in it and how much?

Thanks experts!
  • 2
1 Solution
Just curious, what does just the Win32_PhysicalMemory class alone provide?

using System;
using System.Management;
using System.Windows.Forms;

namespace WMISample
    public class MyWMIQuery
        public static void Main()
                ManagementObjectSearcher searcher =
                    new ManagementObjectSearcher("root\\CIMV2",
                    "SELECT * FROM Win32_PhysicalMemory");

                foreach (ManagementObject queryObj in searcher.Get())
                    Console.WriteLine("Win32_PhysicalMemory instance");
                    Console.WriteLine("BankLabel: {0}", queryObj["BankLabel"]);
                    Console.WriteLine("Capacity: {0}", queryObj["Capacity"]);
                    Console.WriteLine("DataWidth: {0}", queryObj["DataWidth"]);
                    Console.WriteLine("DeviceLocator: {0}", queryObj["DeviceLocator"]);
                    Console.WriteLine("FormFactor: {0}", queryObj["FormFactor"]);
                    Console.WriteLine("Speed: {0}", queryObj["Speed"]);
                    Console.WriteLine("TotalWidth: {0}", queryObj["TotalWidth"]);
                    Console.WriteLine("TypeDetail: {0}", queryObj["TypeDetail"]);
            catch (ManagementException e)
                MessageBox.Show("An error occurred while querying for WMI data: " + e.Message);
rascalAuthor Commented:
Hi graye

I don't have a .net platform handy to run the above, but the equivalent script run in wbemtest showed the 2 sockets in use (out of the 4 on the machine).

All the fields looked normal, but it was telling that the banklabel was 0 and 2 respectively for the 2 sockets. Seems to lend support to the concept that access or visibility to all 4 sockets is blocked, but the ones that do report do show their proper bank label.

I wonder if I should just assume that if there is a gap in the reporting of the sockets that I should just "fill in the gaps" since they always have to appear in 2's?


Perhaps the two pairs of physical "dual port" slots are *supposed* to appear as two logical slots?

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now