How to query Win32_PhysicalMemory instances using WMI in the kernel.
in [Device Drivers]
|
Prev: The intall process of NDIS IM driver hangs in vista sp1
Next: How to send USB control Request by User Mode Application?
From: George M. Garner Jr. on 6 Jan 2009 23:33 Would someone please explain how to use WMI in the kernel to query Win32_PhysicalMemory. Presumably if I knew the correct GUID I could use IoQueryAllData to get all instances of the class into a buffer. But I don't see the GUID published. Thanks, George.
From: George M. Garner Jr. on 11 Jan 2009 22:20 Maxim, Thanks for responding. I need to know the capacity of the memory modules installed on the system without resorting to a lot chipset dependent code. And yes, I know that this information is not always exposed by the ACPI table. It may be that the kernel doesn't expose Win32_PhysicalMemory. But how to use WMI in the kernel is very poorly documented. Regards, George.
From: Maxim S. Shatskih on 12 Jan 2009 01:05 > And yes, I know that this information is not always exposed by the ACPI > table. It may be that the kernel doesn't expose Win32_PhysicalMemory. You can also try MmGetPhysicalMemoryRanges (undocumented), or try to find the SMBIOS table in the memory. >But how to use WMI in the kernel is very poorly documented. Not documented at all. Probably using the helper user mode code is a way. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: David Craig on 12 Jan 2009 01:22 Why not just read the registry? The memory information is contained in a registry key, IIRC '.PhysicalMemory'. "Maxim S. Shatskih" <maxim(a)storagecraft.com.no.spam> wrote in message news:eX$33uHdJHA.4684(a)TK2MSFTNGP03.phx.gbl... > And yes, I know that this information is not always exposed by the ACPI > table. It may be that the kernel doesn't expose Win32_PhysicalMemory. You can also try MmGetPhysicalMemoryRanges (undocumented), or try to find the SMBIOS table in the memory. >But how to use WMI in the kernel is very poorly documented. Not documented at all. Probably using the helper user mode code is a way. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: George M. Garner Jr. on 12 Jan 2009 10:44
Maxim, MmGetPhysicalMemoryRanges only gives you the memory ranges that are visible to the operating system. This can diverge greatly from the total capacity of the memory modules installed. More specifically, on 32-bit Windows client systems the number of phyisical pages visible to the operating system is restricted for licensing reasons to less than 4 GiB of memory. However, it is relatively trivial to write a driver to access the FAM that occupies physical addresses above 4 GiB, and that is being done. Unfortunately, when you develop legitimate software that will be offered for sale you have design constraits that don't affect some others. IoWMIOpenBlock etc ARE documented in the WDK, which is why this question is appropriate here. The SMBIOS table may be located in memory using WMI. That works quite nicely. The problem, aside from some questions about the accuracy of SMBIOS, is that the SMBIOS table is complex. An implementation based on parsing the raw SMBIOS table would need to be tested for a long time and on a large number of systems before it would be safe to use in the kernel. Even if Win32_PhysicalMemory relies on SMBIOS the code base has had thousands of hours of regression testing. That is what makes it the better option. Of course, relying on a user mode helper is an option. But then I would be relying on user mode for a critical element. From a driver developer's perspective, the whole purpose of user mode is to crash the system. If someone does not develop from that perspective then they should not be writing Windows device drivers. Thanks again for taking the time to respond. Regards, George. |