dmidecode reports No SMBIOS nor DMI entry point found (/dev/mem exists, missing 000F0000 range)

Windows Build Number

Microsoft Windows [Version 10.0.19042.928]

WSL Version

• WSL 2
• WSL 1

Kernel Version

Linux version 5.4.72-microsoft-standard-WSL2

Distro Version

Ubuntu 20.04 and openSUSE-Leap-15.2

Other Software

No response

Repro Steps

$ sudo dmidecode
# dmidecode 3.2
Scanning /dev/mem for entry point.
# No SMBIOS nor DMI entry point found, sorry.

The reason is a hole in the range 000F0000 to 000FFFFF where SMBIOS entry point and table is normally found.

sudo hd /dev/mem|more
0009ea70  01 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
0009ea80  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000e0000  52 53 44 20 50 54 52 20  f1 56 52 54 55 41 4c 02  |RSD PTR .VRTUAL.|
000e0010  00 00 10 00 24 00 00 00  00 00 10 00 00 00 00 00  |....$...........|
000e0020  cc 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000e0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000  58 53 44 54 44 00 00 00  01 50 56 52 54 55 41 4c  |XSDTD....PVRTUAL|
00100010  4d 49 43 52 4f 53 46 54  01 00 00 00 4d 53 46 54  |MICROSFT....MSFT|
00100020  01 00 00 00 00 10 10 00  00 00 00 00 54 11 10 00  |............T...|
00100030  00 00 00 00 3c f3 11 00  00 00 00 00 cc f5 11 00  |....<...........|
00100040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

Expected Behavior

Normally SMBIOS is found in /dev/mem in the 000F0000-000FFFFF range. Azure Ubuntu example:

dmidecode -u|more
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 2.3 present.
338 structures occupying 17307 bytes.
Table at 0x000F93D0.
... etc.

Correspondingly /dev/mem (use hd to dump) contains the SMBIOS entry point and table in the expected range:

000f93d0  00 14 00 00 01 02 00 f0  03 03 90 da cb 7f 00 00  |................|
000f93e0  00 00 34 01 41 6d 65 72  69 63 61 6e 20 4d 65 67  |..4.American Meg|
000f93f0  61 74 72 65 6e 64 73 20  49 6e 63 2e 00 30 39 30  |atrends Inc..090|
000f9400  30 30 38 20 00 31 32 2f  30 37 2f 32 30 31 38 00  |008 .12/07/2018.|
000f9410  00 01 19 01 00 01 02 03  04 ad 72 18 0b 34 20 dc  |..........r..4 .|
000f9420  4b 96 5e c7 32 8a 9f 68  c2 06 4d 69 63 72 6f 73  |K.^.2..h..Micros|
000f9430  6f 66 74 20 43 6f 72 70  6f 72 61 74 69 6f 6e 00  |oft Corporation.|
000f9440  56 69 72 74 75 61 6c 20  4d 61 63 68 69 6e 65 00  |Virtual Machine.|
000f9450  37 2e 30 00 30 30 30 30  2d 30 30 30 30 2d 37 39  |7.0.0000-0000-79|
000f9460  39 35 2d 31 35 30 32 2d  31 37 35 33 2d 34 36 39  |95-1502-1753-469|

Actual Behavior

The range 000F0000-000FFFFF is empty.

000e0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000  58 53 44 54 44 00 00 00  01 50 56 52 54 55 41 4c  |XSDTD....PVRTUAL|

Diagnostic Logs

No response

Start by reproducing sudo dmidecode and inspecting /dev/mem under WSL 2, focusing on the missing 000F0000-000FFFFF range. Compare the WSL output with the Azure Ubuntu example in the issue and trace which WSL component exposes the memory mapping. Done means the SMBIOS entry point is available to dmidecode in the reported environments, or the limitation and expected behavior are clearly established.