Displaying memory by physical address early in the boot process.

KD or Windbg will break early in the boot process when started with the -b
or -d options and boot debugging is enabled on the target OS. But I don’t
appear to be able to display any physical memory locations:

Please provide pool address to dump pool. Pool busy/free list not supported
for Vista.
kd> db /p 1000
00001000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
00001010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
00001020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???

kd> !db 1000
Physical memory read at 1000 failed
If you know the caching attributes used for the memory,

But valid virtual addresses do work properly:

kd> dt -b nt!_LOADER_PARAMETER_BLOCK 8080b048
+0x000 OsMajorVersion : 6
+0x004 OsMinorVersion : 1
+0x008 Size : 0x88
+0x00c Reserved : 0
+0x010 LoadOrderListHead : _LIST_ENTRY [0x808d10b8 - 0x808db948]
+0x000 Flink : 0x808d10b8
+0x004 Blink : 0x808db948

I suppose that this is because the debugger is relying on the OS memory
manager to map and read the physical memory location, which hasn’t been
initialized yet. Is that correct? Is there some other way to display
physical addresses using Windbg? Or am I going to have to find an unused
PTE and map the physical address myself (using the debugger)? Any
suggestions would be appreciated.

Regards,

George.

I don’t believe that that address is displayable later on either, by
default, at least.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of George M. Garner Jr.
Sent: Monday, January 10, 2011 11:33 AM
To: Kernel Debugging Interest List
Subject: [windbg] Displaying memory by physical address early in the boot
process.

KD or Windbg will break early in the boot process when started with the -b
or -d options and boot debugging is enabled on the target OS. But I don’t
appear to be able to display any physical memory locations:

Please provide pool address to dump pool. Pool busy/free list not supported
for Vista.
kd> db /p 1000
00001000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
00001010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???
00001020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???

kd> !db 1000
Physical memory read at 1000 failed
If you know the caching attributes used for the memory,

But valid virtual addresses do work properly:

kd> dt -b nt!_LOADER_PARAMETER_BLOCK 8080b048
+0x000 OsMajorVersion : 6
+0x004 OsMinorVersion : 1
+0x008 Size : 0x88
+0x00c Reserved : 0
+0x010 LoadOrderListHead : _LIST_ENTRY [0x808d10b8 - 0x808db948]
+0x000 Flink : 0x808d10b8
+0x004 Blink : 0x808db948

I suppose that this is because the debugger is relying on the OS memory
manager to map and read the physical memory location, which hasn’t been
initialized yet. Is that correct? Is there some other way to display
physical addresses using Windbg? Or am I going to have to find an unused
PTE and map the physical address myself (using the debugger)? Any
suggestions would be appreciated.

Regards,

George.


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Martin,

I don’t believe that that address is displayable later on either, by
default, at least. <

Sure it is, using the /p option:

dd /p [physical_address]

I can map a free PTE manually and display the physical page that I want
using the VA:

kd> !pte 80a08000
VA 80a08000
PDE at C0602028 PTE at C0405040
contains 0000000000193063 contains 0000000000000063
pfn 193 —DA–KWEV pfn 0 —DA–KWEV

kd> db 80a08000 L1000
80a08000 f3 ee 00 f0 f3 ee 00 f0-c3 e2 00 f0 f3 ee 00 f0 …
80a08010 f3 ee 00 f0 54 ff 00 f0-8f 07 00 f0 34 07 00 f0 …T…4…
80a08020 a5 fe 00 f0 87 e9 00 f0-f3 ee 00 f0 f3 ee 00 f0 …
80a08030 f3 ee 00 f0 7f ff 00 f0-57 ef 00 f0 00 00 00 e0 …W…
80a08040 f2 03 00 c0 4d f8 00 f0-41 f8 00 f0 24 9c 00 f0 …M…A…$…
80a08050 39 e7 00 f0 59 f8 00 f0-2e e8 00 f0 d2 ef 00 f0 9…Y…
80a08060 00 e0 00 f0 f2 e6 00 f0-6e fe 00 f0 53 ff 00 f0 …n…S…
80a08070 53 ff 00 f0 a4 f0 00 f0-c7 ef 00 f0 2b 6d 00 c0 S…+m…
80a08080 f3 ee 00 f0 f3 ee 00 f0-f3 ee 00 f0 f3 ee 00 f0 …

Here you see that even firmware reserved pages can be displayed in this way.
Perhaps it is because MmDebugPte has not been initialized yet.

kd> dd nt!MmDebugPte L1
82b80088 00000000

Regards,

George.

> Perhaps it is because MmDebugPte has not been initialized yet.

kd> dd nt!MmDebugPte L1
82b80088 00000000

That’s it! Initialize MmDebugPte and all is joy!

kd> dd nt!MmDebugPte L1
82b80088 00000000
kd> ed nt!MmDebugPte c0405040
kd> dd nt!MmDebugPte L1
82b80088 c0405040
kd> dd /p 1000
00001000 00000000 00000000 00000000 00000000
00001010 00000000 00000000 00000000 00000000
00001020 00000000 00000000 00000000 00000000
00001030 00000000 00000000 00000000 00000000
00001040 00000000 00000000 00000000 00000000
00001050 00000000 00000000 00000000 00000000
00001060 00000000 00000000 00000000 00000000
00001070 00000000 00000000 00000000 00000000

Regards,

George.