Proposal: Change the way MemoryType is obtained on Windows

[xiongnemo]

My Windows laptop showed this:

─ Memory
  ├──  (Part-Number)
  │   ├── Type: Unknown
  │   ├── Slot
  │   │   ├── Bank: BANK 0
  │   │   └── Channel: ChannelA-DIMM0
  │   ├── Frequency (MHz): 2400 MHz
  │   ├── Manufacturer: 04CB
  │   └── Capacity: 8192MB
  └──  (Part-Number)
      ├── Type: Unknown
      ├── Slot
      │   ├── Bank: BANK 2
      │   └── Channel: ChannelB-DIMM0
      ├── Frequency (MHz): 2400 MHz
      ├── Manufacturer: 04CB
      └── Capacity: 8192MB

Corresponding source code：

https://github.com/iabtw/OCSysInfo/blob/da2632b192bd59ff094052326e1f1531da862982/src/dumps/Windows/win.py#L190

According to this link:

Many newer memories do not have a typenumber assigned.  This is- very much true of newer laptops.  THis has nothing to do with VBScript or PowerShell.

My output of wmic:

C:\Users\nemo>wmic memorychip get banklabel, manufacturer, partnumber, speed, MemoryType, SMBIOSMemoryType, devicelocator
BankLabel  DeviceLocator   Manufacturer  MemoryType  PartNumber  SMBIOSMemoryType  Speed
BANK 0     ChannelA-DIMM0  04CB          0                       26                2400
BANK 2     ChannelB-DIMM0  04CB          0                       26                2400

I don't quite know how to fix it without breaking current usage of wmi, but there maybe a solution.

[kernel-dev]

Hm, SMBIOSMemoryType may yield useful results, if the enumerated values are of the same range as that of the MemoryType property.

Thank you for bringing up this issue! I shall get back to you soon with updates.

[kernel-dev]

You may try changing the line in the source code, which you quoted, from MemoryType -> SMBIOSMemoryType, it should yield positive results. We shall, however, need to further investigate if this is a viable option.

For me, it seems like it works ok.

Example

``` ─ Memory ├── F4-2400C15-4GRR (Part-Number) │ ├── Type: DDR4 │ ├── Slot │ │ ├── Bank: BANK 0 │ │ └── Channel: ChannelA-DIMM0 │ ├── Frequency (MHz): 2400 MHz │ ├── Manufacturer: 04CD │ └── Capacity: 4096MB ├── F4-2400C15-4GRR (Part-Number) │ ├── Type: DDR4 │ ├── Slot │ │ ├── Bank: BANK 1 │ │ └── Channel: ChannelA-DIMM1 │ ├── Frequency (MHz): 2400 MHz │ ├── Manufacturer: 04CD │ └── Capacity: 4096MB ├── F4-2400C15-4GRR (Part-Number) │ ├── Type: DDR4 │ ├── Slot │ │ ├── Bank: BANK 2 │ │ └── Channel: ChannelB-DIMM0 │ ├── Frequency (MHz): 2400 MHz │ ├── Manufacturer: 04CD │ └── Capacity: 4096MB └── F4-2400C15-4GRR (Part-Number) ├── Type: DDR4 ├── Slot │ ├── Bank: BANK 3 │ └── Channel: ChannelB-DIMM1 ├── Frequency (MHz): 2400 MHz ├── Manufacturer: 04CD └── Capacity: 4096MB ```

[kernel-dev]

A few unit tests have shown that some hardware (in this example, HP BIOS) will not yield proper results in terms of memory type, but SMBIOSMemoryType might be the most reliable data we can obtain.

• Special thank you to @midi1996 for providing hardware to run the tests on.

This erratic behaviour worries me, as it does not really mean that we're able to extract reliable information without supposedly having to decode DMI tables manually (I don't want to go through the same pain I had to go through with Linux on this implementation).

Further investigation is needed, I will speak to a few individuals who are more proficient in this subject, and see if they'd know we can do it.

For now, I will label this issue as a bug and help needed. Thank you once more for bringing it to our attention.

[xiongnemo]

Thank you for your time and attention on the report 😉

[kernel-dev]

After further reports from users who were willing to test the changes on their hardware were received, it's been established that SMBIOSMemoryType seems to be far more reliable than just MemoryType when attempting to determine the memory module's type using WMI.

• Special thanks to @Joshj23icy for providing a plethora of hardware to test on;
• Special thanks to @midi1996 for doing the same.

However, as previously stated, it would appear that some specific BIOSs seem to not provide valid data regarding the module's type, or cannot detect it at all, thus obtaining this data appears completely impossible on them. If anyone might have an idea of how this may be done, for example on an HP BIOS, please feel free to send me an e-mail or reach out to me on Discord at kernel#0068

For the time being, I will push a change that simply changes MemoryType -> SMBIOSMemoryType, since it would appear that obtaining the MemoryType property does not yield valid results, whilst SMBIOSMemoryType does.

Thank you, once more, @xiongnemo for bringing this issue to light. We appreciate it immensely.

With that being said, I will close this issue now, as it seemed to have been as simple as that.