Re[2]: !wlse extension

WINDBG
41

Thanks Pavel/raj…I would like to ask a clarification about a related point:

In the following the difference between commands is “** User virtual addresses are translated to physical addresses before access”

kd> .process 8225a600
Implicit process is now 8225a600
WARNING: .cache forcedecodeuser is not enabled
kd> .cache

Max cache size is : 1048576 bytes (0x400 KB)
Total memory in cache : 124 bytes (0x1 KB)
Number of regions cached: 2
2 full reads broken into 2 partial reads
counts: 0 cached/2 uncached, 0.00% cached
bytes : 0 cached/12 uncached, 0.00% cached
** Transition PTEs are implicitly decoded
** Prototype PTEs are implicitly decoded

kd> .process /p 8225a600
Implicit process is now 8225a600
.cache forcedecodeuser done
kd> .cache

Max cache size is : 1048576 bytes (0x400 KB)
Total memory in cache : 0 bytes (0 KB)
Number of regions cached: 0
0 full reads broken into 0 partial reads
counts: 0 cached/0 uncached, 0.00% cached
bytes : 0 cached/0 uncached, 0.00% cached
** Transition PTEs are implicitly decoded
** User virtual addresses are translated to physical addresses before access
** Prototype PTEs are implicitly decoded

but…when doing for instance

kd> dd 01530000
01530000 35362e31 38373934 2e31322c 35393936
01530010 4c203236 2e313220 31353537 322c3437


the debugger, anyway, does not perform the virtual->physical address translation (on the behalf of the target CPU MMU) prior to access related RAM locations ?

42

not sure i understood you

dd internally reads Physical using ZwSystemDebugControl in xp or less

On 6/2/12, xxxxx@alice.it wrote:
> Thanks Pavel/raj…I would like to ask a clarification about a related
> point:
>
> In the following the difference between commands is "User virtual
> addresses are translated to physical addresses before access"
>
> kd> .process 8225a600
> Implicit process is now 8225a600
> WARNING: .cache forcedecodeuser is not enabled
> kd> .cache
>
> Max cache size is : 1048576 bytes (0x400 KB)
> Total memory in cache : 124 bytes (0x1 KB)
> Number of regions cached: 2
> 2 full reads broken into 2 partial reads
> counts: 0 cached/2 uncached, 0.00% cached
> bytes : 0 cached/12 uncached, 0.00% cached
> Transition PTEs are implicitly decoded
> Prototype PTEs are implicitly decoded
>
> kd> .process /p 8225a600
> Implicit process is now 8225a600
> .cache forcedecodeuser done
> kd> .cache
>
> Max cache size is : 1048576 bytes (0x400 KB)
> Total memory in cache : 0 bytes (0 KB)
> Number of regions cached: 0
> 0 full reads broken into 0 partial reads
> counts: 0 cached/0 uncached, 0.00% cached
> bytes : 0 cached/0 uncached, 0.00% cached
> Transition PTEs are implicitly decoded
> User virtual addresses are translated to physical addresses before
> access
> Prototype PTEs are implicitly decoded
>
> but…when doing for instance
>
> kd> dd 01530000
> 01530000 35362e31 38373934 2e31322c 35393936
> 01530010 4c203236 2e313220 31353537 322c3437
>
>
> the debugger, anyway, does not perform the virtual->physical address
> translation (on the behalf of the target CPU MMU) prior to access related
> RAM locations ?
>
>
> —
> 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
>

43

> dd internally reads Physical using ZwSystemDebugControl in xp or less

AFAIK dd arg is a VA while !dd use physical address as arg…

so I guess in the first case (dd) the debugger (kd) has to perform virtual->physical translation before to access to the (translated) physical address in target memory

With my question I guessed that virtual->physical translation is carried out anyway both for .process /p that .process /P <> option (in spite of “** User virtual addresses
are translated to physical addresses before access” that exists only for /P option…)

44

user windbg debugging user mode exe in user space

192 218 [3] dbgeng!DumpValues::Dump
26 0 [4] dbgeng!LiveUserTargetInfo::ReadVirtual
52 0 [5] dbgeng!LiveUserTargetInfo::ReadVirtualUncached
15 0 [6] dbgeng!LiveUserDebugServices::ReadVirtual
10 0 [7] kernel32!ReadProcessMemory
3 0 [8] ntdll!ZwReadVirtualMemory
2 0 [9] ntdll!KiFastSystemCall
1 0 [8] ntdll!ZwReadVirtualMemory
22 6 [7] kernel32!ReadProcessMemory
26 28 [6] dbgeng!LiveUserDebugServices::ReadVirtual
84 54 [5] dbgeng!LiveUserTargetInfo::ReadVirtualUncached
30 138 [4] dbgeng!LiveUserTargetInfo::ReadVirtual
217 386 [3] dbgeng!DumpValues::Dump

only Plain ReadProcessMemory

user windbg and lkd fetching dwords for default .process context
(maybe idle or system process)

192 218 [3] dbgeng!DumpValues::Dump
14 0 [4] dbgeng!LocalLiveKernelTargetInfo::ReadVirtual
14 0 [5] dbgeng!ProcessInfo::ForceVaTrans
16 0 [6] dbgeng!ProcessInfo::IsVaTrans
17 16 [5] dbgeng!ProcessInfo::ForceVaTrans
53 33 [4] dbgeng!LocalLiveKernelTargetInfo::ReadVirtual
3 0 [5] kernel32!IsBadWritePtr
19 0 [6] kernel32!_SEH_prolog
29 19 [5] kernel32!IsBadWritePtr
9 0 [6] kernel32!_SEH_epilog
30 28 [5] kernel32!IsBadWritePtr
70 91 [4] dbgeng!LocalLiveKernelTargetInfo::ReadVirtual
21 0 [5] dbgeng!LocalLiveKernelTargetInfo::DebugControl
1 0 [6] ntdll!NtSystemDebugControl
2 0 [6] ntdll!ZwSystemDebugControl
2 0 [7] ntdll!KiFastSystemCall
1 0 [6] ntdll!ZwSystemDebugControl
30 6 [5] dbgeng!LocalLiveKernelTargetInfo::DebugControl
94 127 [4] dbgeng!LocalLiveKernelTargetInfo::ReadVirtual
217 439 [3] dbgeng!DumpValues::Dump

uses ForceVaTrans and then ReadVirtual using ZwDebugSystemControl( SysDbgXXXXXX)

192 218 [3] dbgeng!DumpValues::Dump
14 0 [4] dbgeng!LocalLiveKernelTargetInfo::ReadVirtual
14 0 [5] dbgeng!ProcessInfo::ForceVaTrans
14 0 [6] dbgeng!ProcessInfo::IsVaTrans
17 14 [5] dbgeng!ProcessInfo::ForceVaTrans
54 31 [4] dbgeng!LocalLiveKernelTargetInfo::ReadVirtual
3 0 [5] kernel32!IsBadWritePtr
19 0 [6] kernel32!_SEH_prolog
29 19 [5] kernel32!IsBadWritePtr
9 0 [6] kernel32!_SEH_epilog
30 28 [5] kernel32!IsBadWritePtr
89 89 [4] dbgeng!LocalLiveKernelTargetInfo::ReadVirtual
1 0 [5]
dbgeng!DbsSplayTreedbssplaytreecache::cachenode::GetRoot
9 0 [5]
dbgeng!DbsDoubleList::Node,0,4>::GetHead
98 99 [4] dbgeng!LocalLiveKernelTargetInfo::ReadVirtual
43 0 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
17 0 [6] dbgeng!FormatDisp64
9 0 [7] dbgeng!_aullshr
29 9 [6] dbgeng!FormatDisp64
15 0 [7] dbgeng!PrintStringW
15 0 [8] dbgeng!PrintStringVW
34 0 [9] msvcrt!_vsnwprintf
26 34 [8] dbgeng!PrintStringVW
21 60 [7] dbgeng!PrintStringW
34 90 [6] dbgeng!FormatDisp64
51 124 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
6 0 [6] dbgeng!FormatMachineAddr64
14 0 [7] dbgeng!FormatMachineAddrFlags
12 14 [6] dbgeng!FormatMachineAddr64
33 0 [7] dbgeng!FormatAnyAddr64
15 0 [8] dbgeng!PrintStringW
15 0 [9] dbgeng!PrintStringVW
34 0 [10] msvcrt!_vsnwprintf
26 34 [9] dbgeng!PrintStringVW
21 60 [8] dbgeng!PrintStringW
39 81 [7] dbgeng!FormatAnyAddr64
14 134 [6] dbgeng!FormatMachineAddr64
54 272 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
14 0 [6] dbgeng!KdAddrOut
20 0 [7] dbgeng!AnyMaskOutVa
36 0 [8] dbgeng!IgnoreMaskOut
29 36 [7] dbgeng!AnyMaskOutVa
3 0 [8] dbgeng!__security_check_cookie
32 39 [7] dbgeng!AnyMaskOutVa
18 71 [6] dbgeng!KdAddrOut
73 361 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
7 0 [6] dbgeng!_aullshr
78 368 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
8 0 [6] dbgeng!_allmul
99 376 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
21 0 [6] dbgeng!TargetInfo::ReadAllPhysical
28 0 [7] dbgeng!LocalLiveKernelTargetInfo::ReadPhysical
3 0 [8] kernel32!IsBadWritePtr
19 0 [9] kernel32!_SEH_prolog
29 19 [8] kernel32!IsBadWritePtr
9 0 [9] kernel32!_SEH_epilog
30 28 [8] kernel32!IsBadWritePtr
41 58 [7] dbgeng!LocalLiveKernelTargetInfo::ReadPhysical
21 0 [8] dbgeng!LocalLiveKernelTargetInfo::DebugControl
1 0 [9] ntdll!NtSystemDebugControl
2 0 [9] ntdll!ZwSystemDebugControl
2 0 [10] ntdll!KiFastSystemCall
1 0 [9] ntdll!ZwSystemDebugControl
30 6 [8] dbgeng!LocalLiveKernelTargetInfo::DebugControl
68 94 [7] dbgeng!LocalLiveKernelTargetInfo::ReadPhysical
31 162 [6] dbgeng!TargetInfo::ReadAllPhysical
111 569 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
17 0 [6] dbgeng!FormatDisp64
9 0 [7] dbgeng!_aullshr
29 9 [6] dbgeng!FormatDisp64
15 0 [7] dbgeng!PrintStringW
15 0 [8] dbgeng!PrintStringVW
34 0 [9] msvcrt!_vsnwprintf
26 34 [8] dbgeng!PrintStringVW
21 60 [7] dbgeng!PrintStringW
34 90 [6] dbgeng!FormatDisp64
114 693 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
14 0 [6] dbgeng!KdAddrOut
20 0 [7] dbgeng!AnyMaskOutVa
36 0 [8] dbgeng!IgnoreMaskOut
29 36 [7] dbgeng!AnyMaskOutVa
3 0 [8] dbgeng!__security_check_cookie
32 39 [7] dbgeng!AnyMaskOutVa
18 71 [6] dbgeng!KdAddrOut
119 782 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
7 0 [6] dbgeng!_aullshr
126 789 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
8 0 [6] dbgeng!_allmul
151 797 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
21 0 [6] dbgeng!TargetInfo::ReadAllPhysical
28 0 [7] dbgeng!LocalLiveKernelTargetInfo::ReadPhysical
3 0 [8] kernel32!IsBadWritePtr
19 0 [9] kernel32!_SEH_prolog
29 19 [8] kernel32!IsBadWritePtr
9 0 [9] kernel32!_SEH_epilog
30 28 [8] kernel32!IsBadWritePtr
41 58 [7] dbgeng!LocalLiveKernelTargetInfo::ReadPhysical
21 0 [8] dbgeng!LocalLiveKernelTargetInfo::DebugControl
1 0 [9] ntdll!NtSystemDebugControl
2 0 [9] ntdll!ZwSystemDebugControl
2 0 [10] ntdll!KiFastSystemCall
1 0 [9] ntdll!ZwSystemDebugControl
30 6 [8] dbgeng!LocalLiveKernelTargetInfo::DebugControl
68 94 [7] dbgeng!LocalLiveKernelTargetInfo::ReadPhysical
31 162 [6] dbgeng!TargetInfo::ReadAllPhysical
163 990 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
18 0 [6] dbgeng!FormatDisp64
9 0 [7] dbgeng!_aullshr
30 9 [6] dbgeng!FormatDisp64
15 0 [7] dbgeng!PrintStringW
15 0 [8] dbgeng!PrintStringVW
34 0 [9] msvcrt!_vsnwprintf
26 34 [8] dbgeng!PrintStringVW
21 60 [7] dbgeng!PrintStringW
35 90 [6] dbgeng!FormatDisp64
166 1115 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
14 0 [6] dbgeng!KdAddrOut
20 0 [7] dbgeng!AnyMaskOutVa
36 0 [8] dbgeng!IgnoreMaskOut
29 36 [7] dbgeng!AnyMaskOutVa
3 0 [8] dbgeng!__security_check_cookie
32 39 [7] dbgeng!AnyMaskOutVa
18 71 [6] dbgeng!KdAddrOut
206 1204 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
17 0 [6] dbgeng!FormatDisp64
9 0 [7] dbgeng!_aullshr
29 9 [6] dbgeng!FormatDisp64
15 0 [7] dbgeng!PrintStringW
15 0 [8] dbgeng!PrintStringVW
34 0 [9] msvcrt!_vsnwprintf
26 34 [8] dbgeng!PrintStringVW
21 60 [7] dbgeng!PrintStringW
34 90 [6] dbgeng!FormatDisp64
209 1328 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
14 0 [6] dbgeng!KdAddrOut
20 0 [7] dbgeng!AnyMaskOutVa
36 0 [8] dbgeng!IgnoreMaskOut
29 36 [7] dbgeng!AnyMaskOutVa
3 0 [8] dbgeng!__security_check_cookie
32 39 [7] dbgeng!AnyMaskOutVa
18 71 [6] dbgeng!KdAddrOut
226 1417 [5]
dbgeng!X86MachineInfo::GetVirtualTranslationPhysicalOffsets
115 1742 [4] dbgeng!LocalLiveKernelTargetInfo::ReadVirtual
14 0 [5] dbgeng!KdOut
20 0 [6] dbgeng!AnyMaskOutVa
36 0 [7] dbgeng!IgnoreMaskOut
29 36 [6] dbgeng!AnyMaskOutVa
3 0 [7] dbgeng!__security_check_cookie
32 39 [6] dbgeng!AnyMaskOutVa
18 71 [5] dbgeng!KdOut
136 1831 [4] dbgeng!LocalLiveKernelTargetInfo::ReadVirtual
21 0 [5] dbgeng!LocalLiveKernelTargetInfo::DebugControl
1 0 [6] ntdll!NtSystemDebugControl
2 0 [6] ntdll!ZwSystemDebugControl
2 0 [7] ntdll!KiFastSystemCall
1 0 [6] ntdll!ZwSystemDebugControl
30 6 [5] dbgeng!LocalLiveKernelTargetInfo::DebugControl
149 1867 [4] dbgeng!LocalLiveKernelTargetInfo::ReadVirtual
14 0 [5] dbgeng!KdOut
20 0 [6] dbgeng!AnyMaskOutVa
36 0 [7] dbgeng!IgnoreMaskOut
29 36 [6] dbgeng!AnyMaskOutVa
3 0 [7] dbgeng!__security_check_cookie
32 39 [6] dbgeng!AnyMaskOutVa
18 71 [5] dbgeng!KdOut
175 1956 [4] dbgeng!LocalLiveKernelTargetInfo::ReadVirtual
217 2349 [3] dbgeng!DumpValues::Dump

same routine also uses ReadPhysical()

as pavel clarified and Stressed with OR
/p is user only for current process context
/P is user as well as kernel for all process

On 6/3/12, xxxxx@alice.it wrote:
>> dd internally reads Physical using ZwSystemDebugControl in xp or less
>
> AFAIK dd arg is a VA while !dd use physical address as arg…
>
> so I guess in the first case (dd) the debugger (kd) has to perform
> virtual->physical translation before to access to the (translated) physical
> address in target memory
>
> With my question I guessed that virtual->physical translation is carried out
> anyway both for .process /p that .process /P <> option (in spite of “** User
> virtual addresses
> are translated to physical addresses before access” that exists only for /P
> option…)
>
> —
> 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
></dbssplaytreecache::cachenode>

45

I’m not sure i understood correctly

I suppose what you pasted are the call stacks for dd command in the various cases…for instance here what are the meanings of these entries ?

192 218 [3] dbgeng!DumpValues::Dump
26 0 [4] dbgeng!LiveUserTargetInfo::ReadVirtual
52 0 [5] dbgeng!LiveUserTargetInfo::ReadVirtualUncached
15 0 [6] dbgeng!LiveUserDebugServices::ReadVirtual
10 0 [7] kernel32!ReadProcessMemory
3 0 [8] ntdll!ZwReadVirtualMemory
2 0 [9] ntdll!KiFastSystemCall
1 0 [8] ntdll!ZwReadVirtualMemory
22 6 [7] kernel32!ReadProcessMemory
26 28 [6] dbgeng!LiveUserDebugServices::ReadVirtual
84 54 [5] dbgeng!LiveUserTargetInfo::ReadVirtualUncached
30 138 [4] dbgeng!LiveUserTargetInfo::ReadVirtual
217 386 [3] dbgeng!DumpValues::Dump

Thanks for your patience !

46

those were not call stacks those were output of wt command

wt (trace and watch is kind of automatic single stepping it steps
through all the instructions executed between two points you provide
and log the flow )

so in the quote you re pasted some x function called a y function
which called a Z function and the Z function called

92 218 [3] dbgeng!DumpValues::Dump

so it is 3 level deep from where i started the trace this deepness is
denoted by the 3 in square brackets

this function executes 92 instructions before it calls another function

and all the subfunctions below this call executed 218 instructions
before returning back

26 0 [4] dbgeng!LiveUserTargetInfo::ReadVirtual

which executes 26 instructions before it calls another function and
this call is 4 deep

so ultimately user kernel transition occurs when
ntdll!KiFastSystemCall is called which is 9 deep in the sequence

and from there as you can see the indent gets less and less till we reach back
to where we started viz

217 386 [3] dbgeng!DumpValues::Dump

so the flow of this trace was

X->y->Z->3->4->…>->4->3 whcih will go back to Z and then
finally to X where this specific start was started btw

X call is a breakpoint in dbgeng!ProcessCommands() function

and this call trace is a part of the full trace from that function

On 6/3/12, xxxxx@alice.it wrote:
> I’m not sure i understood correctly
>
> I suppose what you pasted are the call stacks for dd command in the various
> cases…for instance here what are the meanings of these entries ?
>
> 192 218 [3] dbgeng!DumpValues::Dump
> 26 0 [4] dbgeng!LiveUserTargetInfo::ReadVirtual
> 52 0 [5] dbgeng!LiveUserTargetInfo::ReadVirtualUncached
> 15 0 [6] dbgeng!LiveUserDebugServices::ReadVirtual
> 10 0 [7] kernel32!ReadProcessMemory
> 3 0 [8] ntdll!ZwReadVirtualMemory
> 2 0 [9] ntdll!KiFastSystemCall
> 1 0 [8] ntdll!ZwReadVirtualMemory
> 22 6 [7] kernel32!ReadProcessMemory
> 26 28 [6] dbgeng!LiveUserDebugServices::ReadVirtual
> 84 54 [5] dbgeng!LiveUserTargetInfo::ReadVirtualUncached
> 30 138 [4] dbgeng!LiveUserTargetInfo::ReadVirtual
> 217 386 [3] dbgeng!DumpValues::Dump
>
> Thanks for your patience !
>
> —
> 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
>

47

so…is it possible debug a debugger instance (windbg) while debugging a debuggee ?

48

It is actually faster to try instead of asking :slight_smile:

windbg.exe windbg.exe notepad.exe.

L.

49

windbg.exe -p debugging a os which runs a windbg -p
is possible too

windbg is very very flexible you will really fall in love with it if
you understand it :slight_smile:

On 6/4/12, Ladislav Zezula wrote:
> It is actually faster to try instead of asking :slight_smile:
>
> windbg.exe windbg.exe notepad.exe.
>
> L.
>
>
> —
> 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
>

50

and windbg help file is a mine for information
try doing a .dbgdbg from a windbg the sweet child will spawn a
parent to itself :slight_smile:

0:001> .dbgdbg
Debugger spawned, connect with
"-remote npipe:icfenable,pipe=cdb_pipe,server=XXXXXXXXX

On 6/5/12, raj_r wrote:
> windbg.exe -p debugging a os which runs a windbg -p
> is possible too
>
> windbg is very very flexible you will really fall in love with it if
> you understand it :slight_smile:
>
> On 6/4/12, Ladislav Zezula wrote:
>> It is actually faster to try instead of asking :slight_smile:
>>
>> windbg.exe windbg.exe notepad.exe.
>>
>> L.
>>
>>
>> —
>> 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
>>
>

51

and if you dont want to debug but just want to know what kd or windbg
is doing ask it to tell what it is doing with ctrl+alt+d / ctrl+d
and it will bore you with trillions of debug messages

virtually drowning you with innate details of its working:)

On 6/5/12, raj_r wrote:
> and windbg help file is a mine for information
> try doing a .dbgdbg from a windbg the sweet child will spawn a
> parent to itself :slight_smile:
>
> 0:001> .dbgdbg
> Debugger spawned, connect with
> "-remote npipe:icfenable,pipe=cdb_pipe,server=XXXXXXXXX
>
> On 6/5/12, raj_r wrote:
>> windbg.exe -p debugging a os which runs a windbg -p
>> is possible too
>>
>> windbg is very very flexible you will really fall in love with it if
>> you understand it :slight_smile:
>>
>> On 6/4/12, Ladislav Zezula wrote:
>>> It is actually faster to try instead of asking :slight_smile:
>>>
>>> windbg.exe windbg.exe notepad.exe.
>>>
>>> L.
>>>
>>>
>>> —
>>> 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
>>>
>>
>

52

you posted another question asking if windbg breaks in an arbitrary
process context when hitting ctrl+break

this is how windbg tells where it broke

READ: Wait for type 7 packet
Send Break in … <----------------------------------- ctrl+break
READ: Wait for type 7 packet
PacketType=7, ByteCount=f4, PacketId=80800000,
READ: Received Type 7 data packet with id = 80800000 successfully.

READ: Packet type = 7, KdApi64 = 1

>> State change event 3030, proc 0 of 1, str ‘’
Break instruction exception - code 80000003 (first chance)
WRITE: Write type 2 packet
READ: Wait for ACK packet
PacketType=4, ByteCount=0, PacketId=80800000,
READ: Received correct ACK packet.
READ: Wait for type 2 packet
PacketType=2, ByteCount=4a, PacketId=80800001,
READ: Received Type 2 data packet with id = 80800001 successfully.

KdReadVirtual(804e3580, 12) returns 00000000, 12
WRITE: Write type 2 packet
READ: Wait for ACK packet
PacketType=4, ByteCount=0, PacketId=80800001,
READ: Received correct ACK packet.
READ: Wait for type 2 packet
PacketType=2, ByteCount=56, PacketId=80800000,
READ: Received Type 2 data packet with id = 80800000 successfully.

KdReadVirtual(804e35a2, 1e) returns 00000000, 1e
WRITE: Write type 2 packet
READ: Wait for ACK packet
PacketType=4, ByteCount=0, PacketId=80800000,
READ: Received correct ACK packet.
READ: Wait for type 2 packet
PacketType=2, ByteCount=304, PacketId=80800001,
READ: Received Type 2 data packet with id = 80800001 successfully.

DbgKdGetContext(PC 804e3592, SP 80550ed0) returns 00000000
*******************************************************************************
* *
* You are seeing this message because you pressed either *
* CTRL+C (if you run kd.exe) or, *
* CTRL+BREAK (if you run WinDBG), *
* on your debugger machine’s keyboard. *
* *
* THIS IS NOT A BUG OR A SYSTEM CRASH *
* *
* If you did not intend to break into the debugger, press the “g” key, then *
* press the “Enter” key now. This message might immediately reappear. If it *
* does, press “g” and “Enter” again. *
* *
*******************************************************************************
nt!RtlpBreakWithStatusInstruction:
804e3592 cc int 3
WRITE: Write type 2 packet
READ: Wait for ACK packet
PacketType=4, ByteCount=0, PacketId=80800001,
READ: Received correct ACK packet.
READ: Wait for type 2 packet
PacketType=2, ByteCount=138, PacketId=80800000,
READ: Received Type 2 data packet with id = 80800000 successfully.

KdReadVirtual(80550ed0, 100) returns 00000000, 100

On 6/5/12, raj_r wrote:
> and if you dont want to debug but just want to know what kd or windbg
> is doing ask it to tell what it is doing with ctrl+alt+d / ctrl+d
> and it will bore you with trillions of debug messages
>
> virtually drowning you with innate details of its working:)
>
> On 6/5/12, raj_r wrote:
>> and windbg help file is a mine for information
>> try doing a .dbgdbg from a windbg the sweet child will spawn a
>> parent to itself :slight_smile:
>>
>> 0:001> .dbgdbg
>> Debugger spawned, connect with
>> "-remote npipe:icfenable,pipe=cdb_pipe,server=XXXXXXXXX
>>
>> On 6/5/12, raj_r wrote:
>>> windbg.exe -p debugging a os which runs a windbg -p
>>> is possible too
>>>
>>> windbg is very very flexible you will really fall in love with it if
>>> you understand it :slight_smile:
>>>
>>> On 6/4/12, Ladislav Zezula wrote:
>>>> It is actually faster to try instead of asking :slight_smile:
>>>>
>>>> windbg.exe windbg.exe notepad.exe.
>>>>
>>>> L.
>>>>
>>>>
>>>> —
>>>> 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
>>>>
>>>
>>
>

53

Great!

I’ve done a test breaking in the target running an exe (Testlimit.exe -d)

nt!RtlpBreakWithStatusInstruction:
804e3b25 cc int 3

switching to the interesting program context

kd> .process 82227da0
WRITE: Write type 2 packet
READ: Wait for ACK packet
PacketType=4, ByteCount=0, PacketId=80800001,
READ: Received correct ACK packet.
READ: Wait for type 2 packet
PacketType=2, ByteCount=138, PacketId=80800001,
READ: Received Type 2 data packet with id = 80800001 successfully.

KdReadVirtual(80550850, 100) returns 00000000, 100
WRITE: Write type 2 packet
READ: Wait for ACK packet
PacketType=4, ByteCount=0, PacketId=80800000,
READ: Received correct ACK packet.
READ: Wait for type 2 packet
PacketType=2, ByteCount=40, PacketId=80800000,
READ: Received Type 2 data packet with id = 80800000 successfully.

KdReadVirtual(804e389a, 8) returns 00000000, 8
WRITE: Write type 2 packet
READ: Wait for ACK packet
PacketType=4, ByteCount=0, PacketId=80800001,
READ: Received correct ACK packet.
READ: Wait for type 2 packet
PacketType=2, ByteCount=3c, PacketId=80800001,
READ: Received Type 2 data packet with id = 80800001 successfully.

KdReadVirtual(82227db8, 4) returns 00000000, 4
WRITE: Write type 2 packet
READ: Wait for ACK packet
PacketType=4, ByteCount=0, PacketId=80800000,
READ: Received correct ACK packet.
READ: Wait for type 2 packet
PacketType=2, ByteCount=40, PacketId=80800000,
READ: Received Type 2 data packet with id = 80800000 successfully.

KdReadVirtual(8055ab20, 8) returns 00000000, 8
Implicit process is now 82227da0
WARNING: .cache forcedecodeuser is not enabled

dump a virtual address in this context

kd> dd 00a30000
WRITE: Write type 2 packet
READ: Wait for ACK packet
PacketType=4, ByteCount=0, PacketId=80800001,
READ: Received correct ACK packet.
READ: Wait for type 2 packet
PacketType=2, ByteCount=38, PacketId=80800001,
READ: Received Type 2 data packet with id = 80800001 successfully.

KdReadVirtual(00a30000, 80) returns 8007001e, 0
00a30000 ??? ??? ??? ???
00a30010 ??? ??? ??? ???
00a30020 ??? ??? ??? ???
00a30030 ??? ??? ??? ???
00a30040 ??? ??? ??? ???
00a30050 ??? ??? ??? ???
00a30060 ??? ??? ??? ???
00a30070 ??? ??? ??? ???

You can see this address location is invalid; now I use /p option

kd> .process /p 82227da0
WRITE: Write type 2 packet
READ: Wait for ACK packet
PacketType=4, ByteCount=0, PacketId=80800000,
READ: Received correct ACK packet.
READ: Wait for type 2 packet
PacketType=2, ByteCount=3c, PacketId=80800000,
READ: Received Type 2 data packet with id = 80800000 successfully.

KdReadVirtual(82227db8, 4) returns 00000000, 4
WRITE: Write type 2 packet
READ: Wait for ACK packet
PacketType=4, ByteCount=0, PacketId=80800001,
READ: Received correct ACK packet.
READ: Wait for type 2 packet
PacketType=2, ByteCount=40, PacketId=80800001,
READ: Received Type 2 data packet with id = 80800001 successfully.

KdReadVirtual(8055ab20, 8) returns 00000000, 8
Implicit process is now 82227da0
.cache forcedecodeuser done

kd> dd 00a30000
X86VtoP: Virt 00a30000, pagedir 17601000 <---------------------
WRITE: Write type 2 packet
READ: Wait for ACK packet
PacketType=4, ByteCount=0, PacketId=80800000,
READ: Received correct ACK packet.
READ: Wait for type 2 packet
PacketType=2, ByteCount=3c, PacketId=80800000,
READ: Received Type 2 data packet with id = 80800000 successfully.

KdReadPhysical(17601008, 4) returns 00000000, 4
X86VtoP: PDE 17601008 - 17a12047
WRITE: Write type 2 packet
READ: Wait for ACK packet
PacketType=4, ByteCount=0, PacketId=80800001,
READ: Received correct ACK packet.
READ: Wait for type 2 packet
PacketType=2, ByteCount=3c, PacketId=80800001,
READ: Received Type 2 data packet with id = 80800001 successfully.

KdReadPhysical(17a128c0, 4) returns 00000000, 4
X86VtoP: PTE 17a128c0 - 0084f080
X86VtoP: PTE not present, pagefile 0:84f000
00a30000 ??? ??? ??? ???
00a30010 ??? ??? ??? ???
00a30020 ??? ??? ??? ???
00a30030 ??? ??? ??? ???
00a30040 ??? ??? ??? ???
00a30050 ??? ??? ??? ???
00a30060 ??? ??? ??? ???
00a30070 ??? ??? ??? ???

The arrow refers to x86 virtual->physical translation

kd> .cache

Max cache size is : 1048576 bytes (0x400 KB)
Total memory in cache : 48 bytes (0x1 KB)
Number of regions cached: 1
1 full reads broken into 1 partial reads
counts: 0 cached/1 uncached, 0.00% cached
bytes : 0 cached/0 uncached, 0.00% cached
** User virtual addresses are translated to physical addresses before access
** Prototype PTEs are implicitly decoded

Here you can see the translation is actually performed before target memory is accessed. Anyway because the page is in pagefile it can not be accessed.

Do you think that for transition pages (RAM resident in either stanby or modified list) it would be possibile anyway access them ?

54

if you want to view the contents of a page which has been paged out
(user mode space only not kernel space ) then you can use .pagein and
issue a g
when the debugger will break again (like it did for .process /i as in
an earlier post)

the page you want to view contents of will be paged in

01110000 ??? ??? ??? ???
01110010 ??? ??? ??? ???
01110020 ??? ??? ??? ???
01110030 ??? ??? ??? ???
01110040 ??? ??? ??? ???
01110050 ??? ??? ??? ???
01110060 ??? ??? ??? ???
01110070 ??? ??? ??? ???
kd> .pagein 01110000

You need to continue execution (press ‘g’ ) for the pagein to
be brought in. When the debugger breaks in again, the page will be
present.
kd> g

01110000 00000000 00000000 00000000 00000000

On 6/5/12, xxxxx@alice.it wrote:
> Great!
>
> I’ve done a test breaking in the target running an exe (Testlimit.exe -d)
>
> nt!RtlpBreakWithStatusInstruction:
> 804e3b25 cc int 3
>
> switching to the interesting program context
>
> kd> .process 82227da0
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800001,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=138, PacketId=80800001,
> READ: Received Type 2 data packet with id = 80800001 successfully.
>
> KdReadVirtual(80550850, 100) returns 00000000, 100
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800000,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=40, PacketId=80800000,
> READ: Received Type 2 data packet with id = 80800000 successfully.
>
> KdReadVirtual(804e389a, 8) returns 00000000, 8
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800001,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=3c, PacketId=80800001,
> READ: Received Type 2 data packet with id = 80800001 successfully.
>
> KdReadVirtual(82227db8, 4) returns 00000000, 4
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800000,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=40, PacketId=80800000,
> READ: Received Type 2 data packet with id = 80800000 successfully.
>
> KdReadVirtual(8055ab20, 8) returns 00000000, 8
> Implicit process is now 82227da0
> WARNING: .cache forcedecodeuser is not enabled
>
> dump a virtual address in this context
>
> kd> dd 00a30000
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800001,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=38, PacketId=80800001,
> READ: Received Type 2 data packet with id = 80800001 successfully.
>
> KdReadVirtual(00a30000, 80) returns 8007001e, 0
> 00a30000 ??? ??? ??? ???
> 00a30010 ??? ??? ??? ???
> 00a30020 ??? ??? ??? ???
> 00a30030 ??? ??? ??? ???
> 00a30040 ??? ??? ??? ???
> 00a30050 ??? ??? ??? ???
> 00a30060 ??? ??? ??? ???
> 00a30070 ??? ??? ??? ???
>
> You can see this address location is invalid; now I use /p option
>
> kd> .process /p 82227da0
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800000,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=3c, PacketId=80800000,
> READ: Received Type 2 data packet with id = 80800000 successfully.
>
> KdReadVirtual(82227db8, 4) returns 00000000, 4
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800001,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=40, PacketId=80800001,
> READ: Received Type 2 data packet with id = 80800001 successfully.
>
> KdReadVirtual(8055ab20, 8) returns 00000000, 8
> Implicit process is now 82227da0
> .cache forcedecodeuser done
>
> kd> dd 00a30000
> X86VtoP: Virt 00a30000, pagedir 17601000 <---------------------
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800000,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=3c, PacketId=80800000,
> READ: Received Type 2 data packet with id = 80800000 successfully.
>
> KdReadPhysical(17601008, 4) returns 00000000, 4
> X86VtoP: PDE 17601008 - 17a12047
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800001,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=3c, PacketId=80800001,
> READ: Received Type 2 data packet with id = 80800001 successfully.
>
> KdReadPhysical(17a128c0, 4) returns 00000000, 4
> X86VtoP: PTE 17a128c0 - 0084f080
> X86VtoP: PTE not present, pagefile 0:84f000
> 00a30000 ??? ??? ??? ???
> 00a30010 ??? ??? ??? ???
> 00a30020 ??? ??? ??? ???
> 00a30030 ??? ??? ??? ???
> 00a30040 ??? ??? ??? ???
> 00a30050 ??? ??? ??? ???
> 00a30060 ??? ??? ??? ???
> 00a30070 ??? ??? ??? ???
>
> The arrow refers to x86 virtual->physical translation
>
> kd> .cache
>
> Max cache size is : 1048576 bytes (0x400 KB)
> Total memory in cache : 48 bytes (0x1 KB)
> Number of regions cached: 1
> 1 full reads broken into 1 partial reads
> counts: 0 cached/1 uncached, 0.00% cached
> bytes : 0 cached/0 uncached, 0.00% cached
> User virtual addresses are translated to physical addresses before
> access
> Prototype PTEs are implicitly decoded
>
> Here you can see the translation is actually performed before target memory
> is accessed. Anyway because the page is in pagefile it can not be accessed.
>
>
> Do you think that for transition pages (RAM resident in either stanby or
> modified list) it would be possibile anyway access them ?
>
>
> —
> 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
>

55

ok for paged out pages…

but for RAM resident pages in transition (the related PTEs are not valid and in transition) when the debugger is in the process context via .process /p or .process /P it will continue to display page memory content ?

I have not been able to break into a target executable and find some pages in either stanby or modified list…

56

i have not personally tried to view pages that are in transition also
dont think that windbg has a built in bang / dot command to view the
contents of a soft faultable page

iirc convoluted scripts parsing vad prototype pte list etc might be a
candidate for experiment

but if you have access to x64 machine with a latest os win7 maybe i
would give this
!ptelist / !kvas commands from codemachine a test ride

the last time i checked the x86 version of this windbg extesnion it
didn’t load in x86 probably because of msvcrt dll dependencies and i
didnt check it further on first attempt fail

here is a relevent theory / literature and url to the extension

http://www.codemachine.com/article_protopte.html

http://www.codemachine.com/tool_cmkd.html

On 6/5/12, xxxxx@alice.it wrote:
> ok for paged out pages…
>
> but for RAM resident pages in transition (the related PTEs are not valid and
> in transition) when the debugger is in the process context via .process /p
> or .process /P it will continue to display page memory content ?
>
> I have not been able to break into a target executable and find some pages
> in either stanby or modified list…
>
> —
> 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
>

57

.pagein works on kernel VAs, though I think it may require Vista or win7.

From: raj_r
Sent: 6/5/2012 6:34 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Re[2]: !wlse extension

if you want to view the contents of a page which has been paged out
(user mode space only not kernel space ) then you can use .pagein and
issue a g
when the debugger will break again (like it did for .process /i as in
an earlier post)

the page you want to view contents of will be paged in

01110000 ??? ??? ??? ???
01110010 ??? ??? ??? ???
01110020 ??? ??? ??? ???
01110030 ??? ??? ??? ???
01110040 ??? ??? ??? ???
01110050 ??? ??? ??? ???
01110060 ??? ??? ??? ???
01110070 ??? ??? ??? ???
kd> .pagein 01110000

You need to continue execution (press ‘g’ ) for the pagein to
be brought in. When the debugger breaks in again, the page will be
present.
kd> g

01110000 00000000 00000000 00000000 00000000

On 6/5/12, xxxxx@alice.it wrote:
> Great!
>
> I’ve done a test breaking in the target running an exe (Testlimit.exe -d)
>
> nt!RtlpBreakWithStatusInstruction:
> 804e3b25 cc int 3
>
> switching to the interesting program context
>
> kd> .process 82227da0
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800001,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=138, PacketId=80800001,
> READ: Received Type 2 data packet with id = 80800001 successfully.
>
> KdReadVirtual(80550850, 100) returns 00000000, 100
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800000,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=40, PacketId=80800000,
> READ: Received Type 2 data packet with id = 80800000 successfully.
>
> KdReadVirtual(804e389a, 8) returns 00000000, 8
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800001,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=3c, PacketId=80800001,
> READ: Received Type 2 data packet with id = 80800001 successfully.
>
> KdReadVirtual(82227db8, 4) returns 00000000, 4
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800000,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=40, PacketId=80800000,
> READ: Received Type 2 data packet with id = 80800000 successfully.
>
> KdReadVirtual(8055ab20, 8) returns 00000000, 8
> Implicit process is now 82227da0
> WARNING: .cache forcedecodeuser is not enabled
>
> dump a virtual address in this context
>
> kd> dd 00a30000
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800001,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=38, PacketId=80800001,
> READ: Received Type 2 data packet with id = 80800001 successfully.
>
> KdReadVirtual(00a30000, 80) returns 8007001e, 0
> 00a30000 ??? ??? ??? ???
> 00a30010 ??? ??? ??? ???
> 00a30020 ??? ??? ??? ???
> 00a30030 ??? ??? ??? ???
> 00a30040 ??? ??? ??? ???
> 00a30050 ??? ??? ??? ???
> 00a30060 ??? ??? ??? ???
> 00a30070 ??? ??? ??? ???
>
> You can see this address location is invalid; now I use /p option
>
> kd> .process /p 82227da0
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800000,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=3c, PacketId=80800000,
> READ: Received Type 2 data packet with id = 80800000 successfully.
>
> KdReadVirtual(82227db8, 4) returns 00000000, 4
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800001,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=40, PacketId=80800001,
> READ: Received Type 2 data packet with id = 80800001 successfully.
>
> KdReadVirtual(8055ab20, 8) returns 00000000, 8
> Implicit process is now 82227da0
> .cache forcedecodeuser done
>
> kd> dd 00a30000
> X86VtoP: Virt 00a30000, pagedir 17601000 <---------------------
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800000,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=3c, PacketId=80800000,
> READ: Received Type 2 data packet with id = 80800000 successfully.
>
> KdReadPhysical(17601008, 4) returns 00000000, 4
> X86VtoP: PDE 17601008 - 17a12047
> WRITE: Write type 2 packet
> READ: Wait for ACK packet
> PacketType=4, ByteCount=0, PacketId=80800001,
> READ: Received correct ACK packet.
> READ: Wait for type 2 packet
> PacketType=2, ByteCount=3c, PacketId=80800001,
> READ: Received Type 2 data packet with id = 80800001 successfully.
>
> KdReadPhysical(17a128c0, 4) returns 00000000, 4
> X86VtoP: PTE 17a128c0 - 0084f080
> X86VtoP: PTE not present, pagefile 0:84f000
> 00a30000 ??? ??? ??? ???
> 00a30010 ??? ??? ??? ???
> 00a30020 ??? ??? ??? ???
> 00a30030 ??? ??? ??? ???
> 00a30040 ??? ??? ??? ???
> 00a30050 ??? ??? ??? ???
> 00a30060 ??? ??? ??? ???
> 00a30070 ??? ??? ??? ???
>
> The arrow refers to x86 virtual->physical translation
>
> kd> .cache
>
> Max cache size is : 1048576 bytes (0x400 KB)
> Total memory in cache : 48 bytes (0x1 KB)
> Number of regions cached: 1
> 1 full reads broken into 1 partial reads
> counts: 0 cached/1 uncached, 0.00% cached
> bytes : 0 cached/0 uncached, 0.00% cached
> User virtual addresses are translated to physical addresses before
> access
> Prototype PTEs are implicitly decoded
>
> Here you can see the translation is actually performed before target memory
> is accessed. Anyway because the page is in pagefile it can not be accessed.
>
>
> Do you think that for transition pages (RAM resident in either stanby or
> modified list) it would be possibile anyway access them ?
>
>
> —
> 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
>

—
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

58

> .pagein works on kernel VAs, though I think it may require Vista or win7

I also tried with .process /i but it seem can not load in a user paged out page. The only way I found is using .pagein

kd> !process 82206da0 0
PROCESS 82206da0 SessionId: 0 Cid: 03c4 Peb: 7ffde000 ParentCid: 0374
DirBase: 0b414000 ObjectTable: e1ad22a0 HandleCount: 12.
Image: Testlimit.exe

kd> .process /P 82206da0
Implicit process is now 82206da0
.cache forcedecodeptes done
kd> dd 00a30000
00a30000 ??? ??? ??? ???
00a30010 ??? ??? ??? ???
00a30020 ??? ??? ??? ???
00a30030 ??? ??? ??? ???
00a30040 ??? ??? ??? ???
00a30050 ??? ??? ??? ???
00a30060 ??? ??? ??? ???
00a30070 ??? ??? ??? ???
kd> !pte 00a30000
VA 00a30000
PDE at C0300008 PTE at C00028C0
contains 0B72D047 contains 02CC5080
pfn b72d —D—UWEV not valid
PageFile: 0
Offset: 2cc5
Protect: 4 - ReadWrite

kd> .process /i 82206da0
You need to continue execution (press ‘g’ ) for the context
to be switched. When the debugger breaks in again, you will be in
the new process context.
kd> g
Break instruction exception - code 80000003 (first chance)
nt!RtlpBreakWithStatusInstruction:
804e3b25 cc int 3
kd> !pte 00a30000
VA 00a30000
PDE at C0300008 PTE at C00028C0
contains 0B72D047 contains 02CC5080
pfn b72d —D—UWEV not valid
PageFile: 0
Offset: 2cc5
Protect: 4 - ReadWrite

kd> dd 00a30000
00a30000 ??? ??? ??? ???
00a30010 ??? ??? ??? ???
00a30020 ??? ??? ??? ???
00a30030 ??? ??? ??? ???
00a30040 ??? ??? ??? ???
00a30050 ??? ??? ??? ???
00a30060 ??? ??? ??? ???
00a30070 ??? ??? ??? ???

kd> .pagein /p 82206da0 00a30000
You need to continue execution (press ‘g’ ) for the pagein to be brought in. When the debugger breaks in again, the page will be present.
kd> g
Break instruction exception - code 80000003 (first chance)
nt!RtlpBreakWithStatusInstruction:
804e3b25 cc int 3
kd> !pte 00a30000
VA 00a30000
PDE at C0300008 PTE at C00028C0
contains 0B72D067 contains 1CA4A027
pfn b72d —DA–UWEV pfn 1ca4a ----A–UWEV

kd> dd 00a30000
00a30000 00000000 00000000 00000000 00000000
00a30010 00000000 00000000 00000000 00000000
00a30020 00000000 00000000 00000000 00000000
00a30030 00000000 00000000 00000000 00000000
00a30040 00000000 00000000 00000000 00000000
00a30050 00000000 00000000 00000000 00000000
00a30060 00000000 00000000 00000000 00000000
00a30070 00000000 00000000 00000000 00000000

59

Thanks Pavel Lebedynskiy

i quoted from memory when i posted because i hadn’t tried this command
on newer os

but reading help file after your post i see it is mentioned so my
paged out memory has been paged in with new page :slight_smile:

========quote==========

In Windows Server 2003 and Windows XP, you can page in only user-mode
addresses by using .pagein. You can override this restriction by using
the /f switch, but we do not recommend that you use this switch. In
Windows Vista, you can safely page in user-mode and kernel-mode
memory.

Caution If you use .pagein on an address in a kernel stack in Windows
Server 2003 or Windows XP, a bug check might occur.

====/quote=======

On 6/6/12, Pavel Lebedynskiy wrote:
> .pagein works on kernel VAs, though I think it may require Vista or win7.
> ________________________________
> From: raj_r
> Sent: 6/5/2012 6:34 AM
> To: Kernel Debugging Interest List
> Subject: Re: [windbg] Re[2]: !wlse extension
>
> if you want to view the contents of a page which has been paged out
> (user mode space only not kernel space ) then you can use .pagein and
> issue a g
> when the debugger will break again (like it did for .process /i as in
> an earlier post)
>
> the page you want to view contents of will be paged in
>
> 01110000 ??? ??? ??? ???
> 01110010 ??? ??? ??? ???
> 01110020 ??? ??? ??? ???
> 01110030 ??? ??? ??? ???
> 01110040 ??? ??? ??? ???
> 01110050 ??? ??? ??? ???
> 01110060 ??? ??? ??? ???
> 01110070 ??? ??? ??? ???
> kd> .pagein 01110000
>
> You need to continue execution (press ‘g’ ) for the pagein to
> be brought in. When the debugger breaks in again, the page will be
> present.
> kd> g
>
> 01110000 00000000 00000000 00000000 00000000
>
>
>
> On 6/5/12, xxxxx@alice.it wrote:
>> Great!
>>
>> I’ve done a test breaking in the target running an exe (Testlimit.exe -d)
>>
>> nt!RtlpBreakWithStatusInstruction:
>> 804e3b25 cc int 3
>>
>> switching to the interesting program context
>>
>> kd> .process 82227da0
>> WRITE: Write type 2 packet
>> READ: Wait for ACK packet
>> PacketType=4, ByteCount=0, PacketId=80800001,
>> READ: Received correct ACK packet.
>> READ: Wait for type 2 packet
>> PacketType=2, ByteCount=138, PacketId=80800001,
>> READ: Received Type 2 data packet with id = 80800001 successfully.
>>
>> KdReadVirtual(80550850, 100) returns 00000000, 100
>> WRITE: Write type 2 packet
>> READ: Wait for ACK packet
>> PacketType=4, ByteCount=0, PacketId=80800000,
>> READ: Received correct ACK packet.
>> READ: Wait for type 2 packet
>> PacketType=2, ByteCount=40, PacketId=80800000,
>> READ: Received Type 2 data packet with id = 80800000 successfully.
>>
>> KdReadVirtual(804e389a, 8) returns 00000000, 8
>> WRITE: Write type 2 packet
>> READ: Wait for ACK packet
>> PacketType=4, ByteCount=0, PacketId=80800001,
>> READ: Received correct ACK packet.
>> READ: Wait for type 2 packet
>> PacketType=2, ByteCount=3c, PacketId=80800001,
>> READ: Received Type 2 data packet with id = 80800001 successfully.
>>
>> KdReadVirtual(82227db8, 4) returns 00000000, 4
>> WRITE: Write type 2 packet
>> READ: Wait for ACK packet
>> PacketType=4, ByteCount=0, PacketId=80800000,
>> READ: Received correct ACK packet.
>> READ: Wait for type 2 packet
>> PacketType=2, ByteCount=40, PacketId=80800000,
>> READ: Received Type 2 data packet with id = 80800000 successfully.
>>
>> KdReadVirtual(8055ab20, 8) returns 00000000, 8
>> Implicit process is now 82227da0
>> WARNING: .cache forcedecodeuser is not enabled
>>
>> dump a virtual address in this context
>>
>> kd> dd 00a30000
>> WRITE: Write type 2 packet
>> READ: Wait for ACK packet
>> PacketType=4, ByteCount=0, PacketId=80800001,
>> READ: Received correct ACK packet.
>> READ: Wait for type 2 packet
>> PacketType=2, ByteCount=38, PacketId=80800001,
>> READ: Received Type 2 data packet with id = 80800001 successfully.
>>
>> KdReadVirtual(00a30000, 80) returns 8007001e, 0
>> 00a30000 ??? ??? ??? ???
>> 00a30010 ??? ??? ??? ???
>> 00a30020 ??? ??? ??? ???
>> 00a30030 ??? ??? ??? ???
>> 00a30040 ??? ??? ??? ???
>> 00a30050 ??? ??? ??? ???
>> 00a30060 ??? ??? ??? ???
>> 00a30070 ??? ??? ??? ???
>>
>> You can see this address location is invalid; now I use /p option
>>
>> kd> .process /p 82227da0
>> WRITE: Write type 2 packet
>> READ: Wait for ACK packet
>> PacketType=4, ByteCount=0, PacketId=80800000,
>> READ: Received correct ACK packet.
>> READ: Wait for type 2 packet
>> PacketType=2, ByteCount=3c, PacketId=80800000,
>> READ: Received Type 2 data packet with id = 80800000 successfully.
>>
>> KdReadVirtual(82227db8, 4) returns 00000000, 4
>> WRITE: Write type 2 packet
>> READ: Wait for ACK packet
>> PacketType=4, ByteCount=0, PacketId=80800001,
>> READ: Received correct ACK packet.
>> READ: Wait for type 2 packet
>> PacketType=2, ByteCount=40, PacketId=80800001,
>> READ: Received Type 2 data packet with id = 80800001 successfully.
>>
>> KdReadVirtual(8055ab20, 8) returns 00000000, 8
>> Implicit process is now 82227da0
>> .cache forcedecodeuser done
>>
>> kd> dd 00a30000
>> X86VtoP: Virt 00a30000, pagedir 17601000 <---------------------
>> WRITE: Write type 2 packet
>> READ: Wait for ACK packet
>> PacketType=4, ByteCount=0, PacketId=80800000,
>> READ: Received correct ACK packet.
>> READ: Wait for type 2 packet
>> PacketType=2, ByteCount=3c, PacketId=80800000,
>> READ: Received Type 2 data packet with id = 80800000 successfully.
>>
>> KdReadPhysical(17601008, 4) returns 00000000, 4
>> X86VtoP: PDE 17601008 - 17a12047
>> WRITE: Write type 2 packet
>> READ: Wait for ACK packet
>> PacketType=4, ByteCount=0, PacketId=80800001,
>> READ: Received correct ACK packet.
>> READ: Wait for type 2 packet
>> PacketType=2, ByteCount=3c, PacketId=80800001,
>> READ: Received Type 2 data packet with id = 80800001 successfully.
>>
>> KdReadPhysical(17a128c0, 4) returns 00000000, 4
>> X86VtoP: PTE 17a128c0 - 0084f080
>> X86VtoP: PTE not present, pagefile 0:84f000
>> 00a30000 ??? ??? ??? ???
>> 00a30010 ??? ??? ??? ???
>> 00a30020 ??? ??? ??? ???
>> 00a30030 ??? ??? ??? ???
>> 00a30040 ??? ??? ??? ???
>> 00a30050 ??? ??? ??? ???
>> 00a30060 ??? ??? ??? ???
>> 00a30070 ??? ??? ??? ???
>>
>> The arrow refers to x86 virtual->physical translation
>>
>> kd> .cache
>>
>> Max cache size is : 1048576 bytes (0x400 KB)
>> Total memory in cache : 48 bytes (0x1 KB)
>> Number of regions cached: 1
>> 1 full reads broken into 1 partial reads
>> counts: 0 cached/1 uncached, 0.00% cached
>> bytes : 0 cached/0 uncached, 0.00% cached
>> User virtual addresses are translated to physical addresses before
>> access
>> Prototype PTEs are implicitly decoded
>>
>> Here you can see the translation is actually performed before target
>> memory
>> is accessed. Anyway because the page is in pagefile it can not be
>> accessed.
>>
>>
>> Do you think that for transition pages (RAM resident in either stanby or
>> modified list) it would be possibile anyway access them ?
>>
>>
>> —
>> 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
>>
>
> —
> 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
>
>
>
>
> —
> 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

60

Yes, debugger can decode transition PTEs and by default all commands that access virtual memory can see contents of standby/modified pages.

Documentation says this can disabled with .cache nodecodepte but I never tried this myself.

An easy way to create lots of standby pages is to use RAMMap from sysinternals to empty all working sets and then flush the modified list.

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of xxxxx@alice.it [xxxxx@alice.it]
Sent: Tuesday, June 05, 2012 9:31 AM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Re[2]: !wlse extension

ok for paged out pages…

but for RAM resident pages in transition (the related PTEs are not valid and in transition) when the debugger is in the process context via .process /p or .process /P it will continue to display page memory content ?

I have not been able to break into a target executable and find some pages in either stanby or modified list…

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