Is there a way from kernel mode to enumerate the memory modules installed on
a system and their capacities? I know that I can do this from user mode
using WMI (so the functionality has to be there somewhere). But I am
looking for something that can be used from kernel mode.

Regards,

Rossetoecioccolato.

This is chipset- and BIOS- dependent. Some BIOSes do expose this
information to the ACPI table, some do not.

I would never rely on this.

Software doing such tricks is either a) using ACPI, maybe thru WMI, and
working on some chipsets only b) using lots of chipset-dependent logic for each
known chipset and PORTIO driver.

For instance, the Motherboard Monitor by Alexander van Kaam uses the second
way.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"RossettoeCioccolato" <rossetoecioccolato@newsgroup.nospam> wrote in message
news:OAvzS78yHHA.3536@TK2MSFTNGP06.phx.gbl...

Maxim,

I guess what I need is the system address map which is only available from
real mode. Do you know if it is cached anywhere?

Regards,

George.

Are you sure particular DIMMs are listed in this map?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"RossettoeCioccolato" <rossetoecioccolato@newsgroup.nospam> wrote in message
news:u%232hLUJzHHA.3908@TK2MSFTNGP05.phx.gbl...

RossettoeCioccolato wrote:
If what you want is the system address map == a table of which physical
memory addresses correspond to what hardware (RAM, Video, ROM, various
hardware, nonexistent), then that info is very much available inside
Windows (and is different than the memory map before boot).

To gather this information from user mode, enumerate the logical PnP
device tree with the SetupDi... functions and look for the "memory
address resources" of each node. Then sort the result by address.
Common stuff such as system RAM and ROM is listed under some surprising
choices of device node, but all the information is there. Also some bus
drivers redundantly claim all the addresses used by devices behind them.
For portability to computers with different motherboards, be sure to
perform any needed calculations to map bus-relative addresses to
CPU-relative addresses, even though most computers currently sold use
the trivial 1:1 mapping.

I don't know a documented way of doing this enumeration from kernel mode
(the undocumented way is to read the dynamic part of the registry (Enum
and HARDWARE keys) and parse the data).


+++

But if you want a map of which DIMM chips are behind what part of the
CPU physical RAM addresses, you need to look at the SMBIOS or ACPI data
which tend to report this information on modern computers. This
information can be accessed via the WMI API and possibly in some other ways.

--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right.
Information in this posting may not be the official position of Danware
Data A/S, only the personal opinions of the author.

Maxim,

It doesn't. But I don't really need that. I am trying to determine the
maximum valid physical address. In user mode I found that the only reliable
way of doing that was to enumerate the memory modules and add up their
physical capacity. I could easily determine this using WMI. But I don't
think that it is good design to rely on user mode from a kernel driver.

There is, of course, MmHighestPhysicalPage and the like. But that is only
the highest page that is visible to the OS. In my experience it is not
always an accurate measure even of that.

Regards,

Rossetoecioccolato.

Look at "\REGISTRY\MACHINE\HARDWARE\RESOURCEMAP\System Resources\Physical
Memory" This registry entry contains a CM_RESOURCE_LIST structure with the
physical memory the system is using.

--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

"RossettoeCioccolato" <rossetoecioccolato@newsgroup.nospam> wrote in
message news:O21DkVKzHHA.4928@TK2MSFTNGP03.phx.gbl...

Don,

Thanks. I looked at that. It is the same as nt!MmPhysicalMemoryBlock. The
problem with that for my purposes is that it does not describe all of the
memory on a system. Usually there is a region of reserved memory at the top
of the physical address space.

Regards,

George.

Unless you are speaking about the machine with more than 4G of RAM, there is
no need to "determine" it - it is well known in advance. The first
instruction that is fetched and executed following a hardware reset is
located at the physical address 0xFFFFFFF0, so that the maximum valid
physical address is 0xFFFFFFFF
The range from 0xFFFFFFFF-Limit to 0xFFFFFFFF is guaranteed to be always
present, where Limit may be hardware-specifc value (for example, on ICH5 hub
it is 0x7FFFF).


Once you have mentioned "region of reserved memory at the top of the
physical address space", apparently, you just want to find out which memory
range gets decoded by the controller and which is invalid, i.e. you don't
want to limit yourself to getting the info about the main memory, but also to
learn everything about the ranges flash BIOS, IOAPIC, etc map to.


If this is the case, your code has to be specific to the target motherboard,
so that you have to speak to the controller, access IO ports that you don't
own, and, in all respects, do everything you are not supposed to do under
Windows - I don't think WMI may be of great help here. If you need it for a
"contained environment" (i.e. in-house use), then download your target
motherboard's manual, and write your code in accordance with it. However, if
you want to use it in a commercial product, then just give up the whole idea
right on the spot....

Anton Bassov

"RossettoeCioccolato" wrote:

Jakob,

Actually, this might work. Is there pseudo-code available somewhere that
illustrates how this is done?

Regards,

Rossetoecioccolato.

Jakob,

This approach doesn't appear to yield any memory resources above 4 GiB.
According to a note in cfgmgr32.h, "This resource type is currently only
supported in Kernel Mode as
CmResourceTypeMemoryLarge." You can see the effect of this with the memory
resources node of the "System Information" MMC snapin. Memory resources
above 4 GiB are not displayed. Were you only expecting this to work on
systems with less 4 GiB of memory?

Regards,

Rossetoecioccolato.

"Jakob Bohm" <jb@danware.dk> wrote in message
news:unGMZBKzHHA.4928@TK2MSFTNGP03.phx.gbl...
RossettoeCioccolato wrote:
If what you want is the system address map == a table of which physical
memory addresses correspond to what hardware (RAM, Video, ROM, various
hardware, nonexistent), then that info is very much available inside
Windows (and is different than the memory map before boot).

To gather this information from user mode, enumerate the logical PnP
device tree with the SetupDi... functions and look for the "memory
address resources" of each node. Then sort the result by address.
Common stuff such as system RAM and ROM is listed under some surprising
choices of device node, but all the information is there. Also some bus
drivers redundantly claim all the addresses used by devices behind them.
For portability to computers with different motherboards, be sure to
perform any needed calculations to map bus-relative addresses to
CPU-relative addresses, even though most computers currently sold use
the trivial 1:1 mapping.

I don't know a documented way of doing this enumeration from kernel mode
(the undocumented way is to read the dynamic part of the registry (Enum
and HARDWARE keys) and parse the data).


+++

But if you want a map of which DIMM chips are behind what part of the
CPU physical RAM addresses, you need to look at the SMBIOS or ACPI data
which tend to report this information on modern computers. This
information can be accessed via the WMI API and possibly in some other ways.

--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right.
Information in this posting may not be the official position of Danware
Data A/S, only the personal opinions of the author.

Don,

Thanks Don. I think that I can use this for a slightly different purpose.

Do you know if this registry key is updated after MmAddPhysicalMemory is
called?

Regards,

Rossetoecioccolato.

"Don Burn" <burn@stopspam.windrvr.com> wrote in message
news:%23kGlIcKzHHA.748@TK2MSFTNGP04.phx.gbl...