Multiple Methods to Retrieve Total Physical Memory in PowerShell Without WMI

Introduction

In Windows system administration, accurately retrieving the total physical memory is a common operational requirement. Traditionally, Windows Management Instrumentation (WMI) has been the standard interface for querying such system information, where the Get-WmiObjectcmdlet can easily access the Capacity property of the Win32_PhysicalMemory class. However, in certain scenarios, particularly involving remote computer management, WMI's dependency on the DCOM protocol can introduce complexities in permission configuration and network firewall restrictions. Therefore, exploring alternatives that do not rely on WMI holds practical significance.

Limitations of the Performance Counter Method

The user initially attempted to calculate total physical memory using performance counters with the following PowerShell code:

(get-counter -counter "\Memory\Available Bytes").CounterSamples[0].CookedValue + 
(get-counter -counter "\Memory\Committed Bytes").CounterSamples[0].CookedValue

This method theoretically sums available memory and committed memory, but practical testing reveals two main issues: first, the computed value fluctuates across multiple polls, typically around 8,605,425,664 bytes; second, it differs from the fixed value returned by WMI—8,589,934,592 bytes—by approximately 15.5 MB. This inconsistency stems from the dynamic nature of performance counters: available and committed memory change in real-time with system operation, and counters may include components like cache or kernel memory that are not fully accounted for in the total physical capacity, making them unsuitable for precisely obtaining static total physical memory.

Best Practice Using systeminfo.exe

As the best answer in the Q&A data, using the systeminfo.exe command provides a simple and reliable non-WMI solution. This command is a built-in Windows tool, and by parsing the "Total Physical Memory" field in its output, it avoids protocol dependencies. The implementation code is:

(systeminfo | Select-String 'Total Physical Memory:').ToString().Split(':')[1].Trim()

This approach first invokes systeminfo to obtain complete system information, then uses the Select-Stringcmdlet to match the line containing "Total Physical Memory:", converts it to a string, splits it by colon, takes the second part, and trims spaces with Trim(), ultimately yielding a text representation of memory size (e.g., "8,589 MB"). The advantage lies in requiring no additional modules and high compatibility, but the drawback is that the output is a formatted string rather than raw byte values, potentially necessitating unit conversion for further processing.

CIM as a Modern Alternative to WMI

Another significant supplementary approach is using Common Information Model (CIM) instances, which represent an evolution of WMI. CIM defaults to the WS-MAN protocol instead of DCOM, simplifying remote management configuration. Relevant code includes:

get-ciminstance -class "cim_physicalmemory" | % {$_.Capacity}

Or using the more comprehensive Win32_PhysicalMemory class (CIM-compatible):

(Get-CimInstance Win32_PhysicalMemory | Measure-Object -Property capacity -Sum).sum /1gb

The CIM method returns PowerShell objects, supporting direct property access and aggregation operations. For example, the second code snippet uses Measure-Object to sum the capacity property across multiple memory modules and converts it to GB by dividing by 1GB. Note that CIM requires the target system to support WS-MAN 3.0 or later, which may limit its use in older PowerShell versions or systems.

Method Comparison and Selection Recommendations

Evaluating the methods comprehensively: the systeminfo.exe approach is most suitable for scenarios prioritizing speed and compatibility, especially when scripts need to run in diverse environments; the CIM method offers object-oriented operations and precise byte values, ideal for situations requiring further data processing or remote management; the performance counter method is not recommended for total memory queries due to its dynamic nature. In practical applications, selection should be based on specific needs: if only display values are needed, systeminfo suffices; if calculation or formatting is required, CIM is more flexible. For instance, code for formatted output in GB:

Get-CimInstance Win32_PhysicalMemory | Measure-Object -Property capacity -Sum | Foreach {"{0:N2}" -f ([math]::round(($_.Sum / 1GB),2))}

This demonstrates CIM's advantage in data post-processing.

Conclusion

When retrieving total physical memory, avoiding WMI dependency can be achieved through multiple avenues. The systeminfo.exe command stands out as the preferred solution for its simplicity and reliability, while CIM provides a more modern protocol and object-oriented interface. The performance counter method, though intuitive, lacks precision and should be used cautiously. When choosing a method, factors such as compatibility, protocol requirements, and data processing needs must be balanced to ensure the robustness and maintainability of operational scripts.