!wlse extension

I’ve used this command on my laptop

lkd> .process
Implicit process is now 88fc82d8

lkd> !wsle

Working Set @ c0883000
FirstFree 13ee FirstDynamic 17
LastEntry 1893 NextSlot 7 LastInitialized 18c0
NonDirect 733 HashTable c0a84000 HashTableSize 1200

and changing to another process

lkd> .process /P 899bb020
Implicit process is now 899bb020
lkd> !wsle

Working Set @ c0883000
FirstFree 121d FirstDynamic 17
LastEntry 1893 NextSlot 7 LastInitialized 18c0
NonDirect 738 HashTable c0a84000 HashTableSize 1200

information shown seem to refer to the same working set (@ c0883000)

My goal is to see details about processes and system working set lists…but sure I’m wrong in something…Can you help me ?

!wsle 1 should show you the wsle or try this script

lkd> r $t0=0;r $t1= 0xc0883cfc;.while ($t0 < 10) { !wsle 0 poi($t1);r
$t1=$t1+4; r $t0=$t0+1}

Working Set @ c0600203
FirstFree 0 FirstDynamic 0
LastEntry 0 NextSlot 0 LastInitialized 0
NonDirect 0 HashTable 0 HashTableSize 0

Working Set @ c0601203
FirstFree 0 FirstDynamic 0
LastEntry 0 NextSlot 0 LastInitialized 0
NonDirect 0 HashTable 0 HashTableSize 0

Working Set @ c0602203
FirstFree c3516300 FirstDynamic 6
LastEntry c3616300 NextSlot 6 LastInitialized 6
NonDirect c3816300 HashTable 6 HashTableSize c3916300

Working Set @ c0603203
FirstFree e7a16300 FirstDynamic 6
LastEntry ebb16300 NextSlot 6 LastInitialized 6
NonDirect ebd16300 HashTable 6 HashTableSize ebe16300

Working Set @ c0604203
FirstFree 0 FirstDynamic 0
LastEntry 0 NextSlot 0 LastInitialized 0
NonDirect 0 HashTable 0 HashTableSize 0

Working Set @ c0882203
FirstFree 0 FirstDynamic 0
LastEntry 0 NextSlot 0 LastInitialized 0
NonDirect 0 HashTable 0 HashTableSize 0

Working Set @ c0883203
FirstFree 0 FirstDynamic 0
LastEntry 0 NextSlot 0 LastInitialized 0
NonDirect 0 HashTable 0 HashTableSize 0

Working Set @ c0884203
FirstFree 56511977 FirstDynamic ad000100
LastEntry 5ad11971 NextSlot c1b00100 LastInitialized 5450017e
NonDirect f3b10178 HashTable f5422177 HashTableSize 24102177

Working Set @ c0605203
FirstFree 0 FirstDynamic 0
LastEntry 0 NextSlot 0 LastInitialized 0
NonDirect 0 HashTable 0 HashTableSize 0

Working Set @ c0a84203
FirstFree 29000100 FirstDynamic 8900
LastEntry 28800100 NextSlot 145c05 LastInitialized 0
NonDirect 0 HashTable 0 HashTableSize 28900100

Working Set @ c0a85203
FirstFree 0 FirstDynamic 0
LastEntry 59000100 NextSlot 14100 LastInitialized 0
NonDirect 0 HashTable 0 HashTableSize ae00100

Working Set @ c0a86203
FirstFree 0 FirstDynamic 0
LastEntry 0 NextSlot 0 LastInitialized 3cb75
NonDirect 0 HashTable 0 HashTableSize 0

Working Set @ c0a87203
FirstFree 74600100 FirstDynamic d2a7e
LastEntry 0 NextSlot 0 LastInitialized 37400
NonDirect 0 HashTable 0 HashTableSize 74700100

Working Set @ c0a88203
FirstFree 0 FirstDynamic 0
LastEntry 0 NextSlot 0 LastInitialized 0
NonDirect 0 HashTable 0 HashTableSize fd300100

Working Set @ c0885203
FirstFree 2ab20102 FirstDynamic 5aa01902
LastEntry 5a901900 NextSlot 2ac20100 LastInitialized 32c22102
NonDirect 32b20102 HashTable a0420102 HashTableSize 19f20100

Working Set @ c0886203
FirstFree ebb22100 FirstDynamic ebc22100
LastEntry ebd22100 NextSlot ebe22100 LastInitialized ec022100
NonDirect ec122100 HashTable ec222100 HashTableSize ec322100

On 5/16/12, xxxxx@alice.it wrote:
> I’ve used this command on my laptop
>
> lkd> .process
> Implicit process is now 88fc82d8
>
> lkd> !wsle
>
> Working Set @ c0883000
> FirstFree 13ee FirstDynamic 17
> LastEntry 1893 NextSlot 7 LastInitialized 18c0
> NonDirect 733 HashTable c0a84000 HashTableSize 1200
>
> and changing to another process
>
> lkd> .process /P 899bb020
> Implicit process is now 899bb020
> lkd> !wsle
>
> Working Set @ c0883000
> FirstFree 121d FirstDynamic 17
> LastEntry 1893 NextSlot 7 LastInitialized 18c0
> NonDirect 738 HashTable c0a84000 HashTableSize 1200
>
> information shown seem to refer to the same working set (@ c0883000)
>
> My goal is to see details about processes and system working set
> lists…but sure I’m wrong in something…Can you help me ?
>
> —
> 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
>

oops hit the button too soon
the constant that i used 0xc0883cfc may be different for you
it is at Default working set list +0x14

try doing dd c00… whatever you get from windbg and at +0x14
(after the next slot)
it contains the list of wsle data which is returned by !wsle 1 or !wsle 2

On 5/17/12, raj_r wrote:
> !wsle 1 should show you the wsle or try this script
>
> lkd> r $t0=0;r $t1= 0xc0883cfc;.while ($t0 < 10) { !wsle 0 poi($t1);r
> $t1=$t1+4; r $t0=$t0+1}
>
> Working Set @ c0600203
> FirstFree 0 FirstDynamic 0
> LastEntry 0 NextSlot 0 LastInitialized 0
> NonDirect 0 HashTable 0 HashTableSize 0
>
> Working Set @ c0601203
> FirstFree 0 FirstDynamic 0
> LastEntry 0 NextSlot 0 LastInitialized 0
> NonDirect 0 HashTable 0 HashTableSize 0
>
> Working Set @ c0602203
> FirstFree c3516300 FirstDynamic 6
> LastEntry c3616300 NextSlot 6 LastInitialized 6
> NonDirect c3816300 HashTable 6 HashTableSize c3916300
>
> Working Set @ c0603203
> FirstFree e7a16300 FirstDynamic 6
> LastEntry ebb16300 NextSlot 6 LastInitialized 6
> NonDirect ebd16300 HashTable 6 HashTableSize ebe16300
>
> Working Set @ c0604203
> FirstFree 0 FirstDynamic 0
> LastEntry 0 NextSlot 0 LastInitialized 0
> NonDirect 0 HashTable 0 HashTableSize 0
>
> Working Set @ c0882203
> FirstFree 0 FirstDynamic 0
> LastEntry 0 NextSlot 0 LastInitialized 0
> NonDirect 0 HashTable 0 HashTableSize 0
>
> Working Set @ c0883203
> FirstFree 0 FirstDynamic 0
> LastEntry 0 NextSlot 0 LastInitialized 0
> NonDirect 0 HashTable 0 HashTableSize 0
>
> Working Set @ c0884203
> FirstFree 56511977 FirstDynamic ad000100
> LastEntry 5ad11971 NextSlot c1b00100 LastInitialized 5450017e
> NonDirect f3b10178 HashTable f5422177 HashTableSize 24102177
>
> Working Set @ c0605203
> FirstFree 0 FirstDynamic 0
> LastEntry 0 NextSlot 0 LastInitialized 0
> NonDirect 0 HashTable 0 HashTableSize 0
>
> Working Set @ c0a84203
> FirstFree 29000100 FirstDynamic 8900
> LastEntry 28800100 NextSlot 145c05 LastInitialized 0
> NonDirect 0 HashTable 0 HashTableSize 28900100
>
> Working Set @ c0a85203
> FirstFree 0 FirstDynamic 0
> LastEntry 59000100 NextSlot 14100 LastInitialized 0
> NonDirect 0 HashTable 0 HashTableSize ae00100
>
> Working Set @ c0a86203
> FirstFree 0 FirstDynamic 0
> LastEntry 0 NextSlot 0 LastInitialized 3cb75
> NonDirect 0 HashTable 0 HashTableSize 0
>
> Working Set @ c0a87203
> FirstFree 74600100 FirstDynamic d2a7e
> LastEntry 0 NextSlot 0 LastInitialized 37400
> NonDirect 0 HashTable 0 HashTableSize 74700100
>
> Working Set @ c0a88203
> FirstFree 0 FirstDynamic 0
> LastEntry 0 NextSlot 0 LastInitialized 0
> NonDirect 0 HashTable 0 HashTableSize fd300100
>
> Working Set @ c0885203
> FirstFree 2ab20102 FirstDynamic 5aa01902
> LastEntry 5a901900 NextSlot 2ac20100 LastInitialized 32c22102
> NonDirect 32b20102 HashTable a0420102 HashTableSize 19f20100
>
> Working Set @ c0886203
> FirstFree ebb22100 FirstDynamic ebc22100
> LastEntry ebd22100 NextSlot ebe22100 LastInitialized ec022100
> NonDirect ec122100 HashTable ec222100 HashTableSize ec322100
>
>
> On 5/16/12, xxxxx@alice.it wrote:
>> I’ve used this command on my laptop
>>
>> lkd> .process
>> Implicit process is now 88fc82d8
>>
>> lkd> !wsle
>>
>> Working Set @ c0883000
>> FirstFree 13ee FirstDynamic 17
>> LastEntry 1893 NextSlot 7 LastInitialized 18c0
>> NonDirect 733 HashTable c0a84000 HashTableSize 1200
>>
>> and changing to another process
>>
>> lkd> .process /P 899bb020
>> Implicit process is now 899bb020
>> lkd> !wsle
>>
>> Working Set @ c0883000
>> FirstFree 121d FirstDynamic 17
>> LastEntry 1893 NextSlot 7 LastInitialized 18c0
>> NonDirect 738 HashTable c0a84000 HashTableSize 1200
>>
>> information shown seem to refer to the same working set (@ c0883000)
>>
>> My goal is to see details about processes and system working set
>> lists…but sure I’m wrong in something…Can you help me ?
>>
>> —
>> 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
>>
>

> the constant that i used 0xc0883cfc may be different for you…

Same value also in my case

lkd> dd c0883000
c0883000 00000000 00000912 00000010 00000ca7
c0883010 00000007 c0883cfc 00000cc0 000003cc

it is at Default working set list +0x14…

what/which is the " Default working set list" ? is it related to the current “implicit” process ?

lkd> !for_each_process “dt nt!_EPROCESS Vm.vmworkingsetlist->Wsle
@#Process;dt nt!_EPROCESS imageFilename @#Process
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc0883cfc _MMWSLE
+0x174 ImageFileName : [16] “System”
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc0883cfc _MMWSLE
+0x174 ImageFileName : [16] “smss.exe”
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc0883cfc _MMWSLE
+0x174 ImageFileName : [16] “csrss.exe”
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc0883cfc _MMWSLE
+0x174 ImageFileName : [16] “winlogon.exe”
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc0883cfc _MMWSLE
+0x174 ImageFileName : [16] “services.exe”
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc0883cfc _MMWSLE
+0x174 ImageFileName : [16] “lsass.exe”
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc0883cfc _MMWSLE
+0x174 ImageFileName : [16] “svchost.exe”
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc0883cfc _MMWSLE
+0x174 ImageFileName : [16] “svchost.exe”
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc0883cfc _MMWSLE
+0x174 ImageFileName : [16] “svchost.exe”
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc0883cfc _MMWSLE
+0x174 ImageFileName : [16] “svchost.exe”
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc0883cfc _MMWSLE
+0x174 ImageFileName : [16] “svchost.exe”
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc0883cfc _MMWSLE

On 5/17/12, xxxxx@alice.it wrote:
>> the constant that i used 0xc0883cfc may be different for you…
>
> Same value also in my case
>
> lkd> dd c0883000
> c0883000 00000000 00000912 00000010 00000ca7
> c0883010 00000007 c0883cfc 00000cc0 000003cc
> …
>
>> it is at Default working set list +0x14…
>
> what/which is the " Default working set list" ? is it related to the current
> “implicit” process ?
>
> —
> 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
>

Help ! I’m a newbie here…it seem to me that for each process WLSE entries maps to the same virtual address 0xc0883cfc. This is an address in system (kernel) virtual address space so I guess is common to all process’s contexts

Here i can see the first WLSE entry:

lkd> dt nt!_MMWSLENTRY c0883cfc
+0x000 Valid : 0y1
+0x000 LockedInWs : 0y1
+0x000 LockedInMemory : 0y0
+0x000 Protection : 0y00000 (0)
+0x000 Hashed : 0y0
+0x000 Direct : 0y1
+0x000 Age : 0y00
+0x000 VirtualPageNumber : 0y11000000011000000000 (0xc0600)

If I change current “implicit” process (.process /P 899bb020) I see same content for WSLE at 0xc0883cfc…Why ?

btw i assume you know using lkd on dynamic structures wont have
consistent results

lkd> dd c0883000
c0883000 00000000 00000912 00000010 00000ca7
c0883010 00000007 c0883cfc 00000cc0 000003cc

if you do it ten times in a row

the (firstfree )0x912 @ + 0x04 in the display etc will be may be
different every time you do it depending on working set trimming
threads operation in background as lkd uses a snapshot

if you want consistent and same results to compare use kernel
debugging freeze the os and watch the working set output in a kd

also i assume you know that the pointer at 0xc0883cfc ie c0600203 etc
is a BitMap and not an address

lkd> .printf “(mmwsl *)%y\n(mmwsle *)%y\n” ,0xc0883000,@@masm(poi(c0883000+14))
(mmwsl *)c0883000
(mmwsle *)c0883cfc

lkd> dt nt!_mmwsle u1.e1. (0xc0883cfc)
+0x000 u1 :
+0x000 e1 :
+0x000 Valid : 0y1
+0x000 LockedInWs : 0y1
+0x000 LockedInMemory : 0y0
+0x000 Protection : 0y00000 (0)
+0x000 Hashed : 0y0
+0x000 Direct : 0y1
+0x000 Age : 0y00
+0x000 VirtualPageNumber : 0y11000000011000000000 (0xc0600)

On 5/17/12, raj_r wrote:
> lkd> !for_each_process “dt nt!_EPROCESS Vm.vmworkingsetlist->Wsle
> @#Process;dt nt!_EPROCESS imageFilename @#Process
> +0x1f8 Vm :
> +0x020 VmWorkingSetList :
> +0x014 Wsle : 0xc0883cfc _MMWSLE
> +0x174 ImageFileName : [16] “System”
> +0x1f8 Vm :
> +0x020 VmWorkingSetList :
> +0x014 Wsle : 0xc0883cfc _MMWSLE
> +0x174 ImageFileName : [16] “smss.exe”
> +0x1f8 Vm :
> +0x020 VmWorkingSetList :
> +0x014 Wsle : 0xc0883cfc _MMWSLE
> +0x174 ImageFileName : [16] “csrss.exe”
> +0x1f8 Vm :
> +0x020 VmWorkingSetList :
> +0x014 Wsle : 0xc0883cfc _MMWSLE
> +0x174 ImageFileName : [16] “winlogon.exe”
> +0x1f8 Vm :
> +0x020 VmWorkingSetList :
> +0x014 Wsle : 0xc0883cfc _MMWSLE
> +0x174 ImageFileName : [16] “services.exe”
> +0x1f8 Vm :
> +0x020 VmWorkingSetList :
> +0x014 Wsle : 0xc0883cfc _MMWSLE
> +0x174 ImageFileName : [16] “lsass.exe”
> +0x1f8 Vm :
> +0x020 VmWorkingSetList :
> +0x014 Wsle : 0xc0883cfc _MMWSLE
> +0x174 ImageFileName : [16] “svchost.exe”
> +0x1f8 Vm :
> +0x020 VmWorkingSetList :
> +0x014 Wsle : 0xc0883cfc _MMWSLE
> +0x174 ImageFileName : [16] “svchost.exe”
> +0x1f8 Vm :
> +0x020 VmWorkingSetList :
> +0x014 Wsle : 0xc0883cfc _MMWSLE
> +0x174 ImageFileName : [16] “svchost.exe”
> +0x1f8 Vm :
> +0x020 VmWorkingSetList :
> +0x014 Wsle : 0xc0883cfc _MMWSLE
> +0x174 ImageFileName : [16] “svchost.exe”
> +0x1f8 Vm :
> +0x020 VmWorkingSetList :
> +0x014 Wsle : 0xc0883cfc _MMWSLE
> +0x174 ImageFileName : [16] “svchost.exe”
> +0x1f8 Vm :
> +0x020 VmWorkingSetList :
> +0x014 Wsle : 0xc0883cfc _MMWSLE
>
>
> On 5/17/12, xxxxx@alice.it wrote:
>>> the constant that i used 0xc0883cfc may be different for you…
>>
>> Same value also in my case
>>
>> lkd> dd c0883000
>> c0883000 00000000 00000912 00000010 00000ca7
>> c0883010 00000007 c0883cfc 00000cc0 000003cc
>> …
>>
>>> it is at Default working set list +0x14…
>>
>> what/which is the " Default working set list" ? is it related to the
>> current
>> “implicit” process ?
>>
>> —
>> 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
>>
>

i remember reading somewhere (probably david probert series of ppts)
c0400000 to c0800000 is hyperspace (x86 working set list)
c0800000 to c0c00000 is unused no access
c0c00000 to c1000000 is system working set list

you can do

lkd> ? poi(nt!MmWorkingSetList)
Evaluate expression: -1064816640 = c0883000

lkd> ? poi(nt!MmSystemCacheWorkingSetList)
Evaluate expression: -1059061760 = c0e00000

and i never though about why it is same in all process may be someone
else could explain

On 5/17/12, raj_r wrote:
> btw i assume you know using lkd on dynamic structures wont have
> consistent results
>
> lkd> dd c0883000
> c0883000 00000000 00000912 00000010 00000ca7
> c0883010 00000007 c0883cfc 00000cc0 000003cc
>
> if you do it ten times in a row
>
> the (firstfree )0x912 @ + 0x04 in the display etc will be may be
> different every time you do it depending on working set trimming
> threads operation in background as lkd uses a snapshot
>
>
> if you want consistent and same results to compare use kernel
> debugging freeze the os and watch the working set output in a kd
>
> also i assume you know that the pointer at 0xc0883cfc ie c0600203 etc
> is a BitMap and not an address
>
> lkd> .printf “(mmwsl *)%y\n(mmwsle *)%y\n”
> ,0xc0883000,@@masm(poi(c0883000+14))
> (mmwsl *)c0883000
> (mmwsle *)c0883cfc
>
> lkd> dt nt!_mmwsle u1.e1. (0xc0883cfc)
> +0x000 u1 :
> +0x000 e1 :
> +0x000 Valid : 0y1
> +0x000 LockedInWs : 0y1
> +0x000 LockedInMemory : 0y0
> +0x000 Protection : 0y00000 (0)
> +0x000 Hashed : 0y0
> +0x000 Direct : 0y1
> +0x000 Age : 0y00
> +0x000 VirtualPageNumber : 0y11000000011000000000 (0xc0600)
>
>
>
> On 5/17/12, raj_r wrote:
>> lkd> !for_each_process “dt nt!_EPROCESS Vm.vmworkingsetlist->Wsle
>> @#Process;dt nt!_EPROCESS imageFilename @#Process
>> +0x1f8 Vm :
>> +0x020 VmWorkingSetList :
>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>> +0x174 ImageFileName : [16] “System”
>> +0x1f8 Vm :
>> +0x020 VmWorkingSetList :
>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>> +0x174 ImageFileName : [16] “smss.exe”
>> +0x1f8 Vm :
>> +0x020 VmWorkingSetList :
>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>> +0x174 ImageFileName : [16] “csrss.exe”
>> +0x1f8 Vm :
>> +0x020 VmWorkingSetList :
>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>> +0x174 ImageFileName : [16] “winlogon.exe”
>> +0x1f8 Vm :
>> +0x020 VmWorkingSetList :
>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>> +0x174 ImageFileName : [16] “services.exe”
>> +0x1f8 Vm :
>> +0x020 VmWorkingSetList :
>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>> +0x174 ImageFileName : [16] “lsass.exe”
>> +0x1f8 Vm :
>> +0x020 VmWorkingSetList :
>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>> +0x174 ImageFileName : [16] “svchost.exe”
>> +0x1f8 Vm :
>> +0x020 VmWorkingSetList :
>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>> +0x174 ImageFileName : [16] “svchost.exe”
>> +0x1f8 Vm :
>> +0x020 VmWorkingSetList :
>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>> +0x174 ImageFileName : [16] “svchost.exe”
>> +0x1f8 Vm :
>> +0x020 VmWorkingSetList :
>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>> +0x174 ImageFileName : [16] “svchost.exe”
>> +0x1f8 Vm :
>> +0x020 VmWorkingSetList :
>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>> +0x174 ImageFileName : [16] “svchost.exe”
>> +0x1f8 Vm :
>> +0x020 VmWorkingSetList :
>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>>
>>
>> On 5/17/12, xxxxx@alice.it wrote:
>>>> the constant that i used 0xc0883cfc may be different for you…
>>>
>>> Same value also in my case
>>>
>>> lkd> dd c0883000
>>> c0883000 00000000 00000912 00000010 00000ca7
>>> c0883010 00000007 c0883cfc 00000cc0 000003cc
>>> …
>>>
>>>> it is at Default working set list +0x14…
>>>
>>> what/which is the " Default working set list" ? is it related to the
>>> current
>>> “implicit” process ?
>>>
>>> —
>>> 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
>>>
>>
>

well even though the address seem to be same the contents differ based
on process

to confirm compile these few lines into two executables by making a
difference between them as follows

Comparing files WsleTestOne.cpp and WSLETESTTWO.CPP
***** WsleTestOne.cpp
200,
“WsleTestOne Alloted This Page\n”
);
***** WSLETESTTWO.CPP
200,
“WsleTestTwo Alloted This Page\n”
);
*****

#include <windows.h>
#include <stdio.h>
int main(void)
{
printf(
“lets test wsle entries by alloting a page writing to \n”
“that page and checking that page in wsldata as mmwsl* \n”
“for all processes seems to be located at same Address \n”
);
LPVOID PageAllot;
if (( PageAllot = VirtualAlloc(
NULL,
4096,
MEM_COMMIT | MEM_RESERVE,
PAGE_EXECUTE_READWRITE
) ) == 0 ) {
printf(
“virtual Alloc Failed\n”
);
return 0;
}
printf (
“Page Allocated at %p\n”,
PageAllot
);
sprintf_s(
(char )PageAllot,
200,
“WsleTestOne Alloted This Page\n”
);
DebugBreak();
VirtualFree(
NULL,
1000,
MEM_RELEASE
);
return 1;
}

run the first app and let it break in kd

when it breaks assemble an infinte jmp (0xeb 0xfe ) at the return
address on stack and hit G
the app will be spinning indefinitely

launch the second executable and let it break in kd

when it broke you will have two executables with just minor
differences and you compare the
pages

even though the address 0xc088 whatever appears to be same
the page contents will definately not be the same

see below an output

kd> !grep -i -b2 -a1 -e “wsle” -c “!process 0 0”
PROCESS ffa21228 SessionId: 0 Cid: 07f0 Peb: 7ffdc000 ParentCid: 0574
DirBase: 0255d000 ObjectTable: e1bf01a0 HandleCount: 7.
Image: WsleTestTwo.exe

PROCESS ff9d4250 SessionId: 0 Cid: 0104 Peb: 7ffd4000 ParentCid: 0574
DirBase: 046bb000 ObjectTable: e1750be0 HandleCount: 7.
Image: WsleTestOne.exe

kd> .process /p ffa21228
Implicit process is now ffa21228
.cache forcedecodeuser done
kd> .shell -ci "r $t0 = 0; .while ( $t0< 0xd3 ) { dc /c 8
(poi(0xc050369c+($t0
4))&0xfffff000) l 8; r $t0 = $t0+1}" grep -i
“wsle”
00350000 656c7357 74736554 206f7754 6f6c6c41 20646574 73696854
67615020 00000a65 WsleTestTwo Alloted This Page…
.shell: Process exited
kd> .process /p ff9d4250
Implicit process is now ff9d4250
.cache forcedecodeuser done
kd> .shell -ci “r $t0 = 0; .while ( $t0< 0xd3 ) { dc /c 8
(poi(0xc050369c+($t0*4))&0xfffff000) l 8; r $t0 = $t0+1}” grep -i
“wsle”
00350000 656c7357 74736554 20656e4f 6f6c6c41 20646574 73696854
67615020 00000a65 WsleTestOne Alloted This Page…
.shell: Process exited
kd> dt nt!_EPROCESS vm.vmworkingsetlist ffa21228
+0x1f8 Vm :
+0x020 VmWorkingSetList : 0xc0503000 _MMWSL
kd> dt nt!_EPROCESS vm.vmworkingsetlist ff9d4250
+0x1f8 Vm :
+0x020 VmWorkingSetList : 0xc0503000 _MMWSL
kd> dt nt!_EPROCESS vm.vmworkingsetlist->Wsle ffa21228
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc050369c _MMWSLE
kd> dt nt!_EPROCESS vm.vmworkingsetlist->Wsle ff9d4250
+0x1f8 Vm :
+0x020 VmWorkingSetList :
+0x014 Wsle : 0xc050369c _MMWSLE

On 5/17/12, raj_r wrote:
> i remember reading somewhere (probably david probert series of ppts)
> c0400000 to c0800000 is hyperspace (x86 working set list)
> c0800000 to c0c00000 is unused no access
> c0c00000 to c1000000 is system working set list
>
> you can do
>
> lkd> ? poi(nt!MmWorkingSetList)
> Evaluate expression: -1064816640 = c0883000
>
> lkd> ? poi(nt!MmSystemCacheWorkingSetList)
> Evaluate expression: -1059061760 = c0e00000
>
> and i never though about why it is same in all process may be someone
> else could explain
>
>
> On 5/17/12, raj_r wrote:
>> btw i assume you know using lkd on dynamic structures wont have
>> consistent results
>>
>> lkd> dd c0883000
>> c0883000 00000000 00000912 00000010 00000ca7
>> c0883010 00000007 c0883cfc 00000cc0 000003cc
>>
>> if you do it ten times in a row
>>
>> the (firstfree )0x912 @ + 0x04 in the display etc will be may be
>> different every time you do it depending on working set trimming
>> threads operation in background as lkd uses a snapshot
>>
>>
>> if you want consistent and same results to compare use kernel
>> debugging freeze the os and watch the working set output in a kd
>>
>> also i assume you know that the pointer at 0xc0883cfc ie c0600203 etc
>> is a BitMap and not an address
>>
>> lkd> .printf “(mmwsl *)%y\n(mmwsle *)%y\n”
>> ,0xc0883000,@@masm(poi(c0883000+14))
>> (mmwsl *)c0883000
>> (mmwsle *)c0883cfc
>>
>> lkd> dt nt!_mmwsle u1.e1. (0xc0883cfc)
>> +0x000 u1 :
>> +0x000 e1 :
>> +0x000 Valid : 0y1
>> +0x000 LockedInWs : 0y1
>> +0x000 LockedInMemory : 0y0
>> +0x000 Protection : 0y00000 (0)
>> +0x000 Hashed : 0y0
>> +0x000 Direct : 0y1
>> +0x000 Age : 0y00
>> +0x000 VirtualPageNumber : 0y11000000011000000000 (0xc0600)
>>
>>
>>
>> On 5/17/12, raj_r wrote:
>>> lkd> !for_each_process “dt nt!_EPROCESS Vm.vmworkingsetlist->Wsle
>>> @#Process;dt nt!_EPROCESS imageFilename @#Process
>>> +0x1f8 Vm :
>>> +0x020 VmWorkingSetList :
>>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>>> +0x174 ImageFileName : [16] “System”
>>> +0x1f8 Vm :
>>> +0x020 VmWorkingSetList :
>>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>>> +0x174 ImageFileName : [16] “smss.exe”
>>> +0x1f8 Vm :
>>> +0x020 VmWorkingSetList :
>>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>>> +0x174 ImageFileName : [16] “csrss.exe”
>>> +0x1f8 Vm :
>>> +0x020 VmWorkingSetList :
>>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>>> +0x174 ImageFileName : [16] “winlogon.exe”
>>> +0x1f8 Vm :
>>> +0x020 VmWorkingSetList :
>>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>>> +0x174 ImageFileName : [16] “services.exe”
>>> +0x1f8 Vm :
>>> +0x020 VmWorkingSetList :
>>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>>> +0x174 ImageFileName : [16] “lsass.exe”
>>> +0x1f8 Vm :
>>> +0x020 VmWorkingSetList :
>>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>>> +0x174 ImageFileName : [16] “svchost.exe”
>>> +0x1f8 Vm :
>>> +0x020 VmWorkingSetList :
>>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>>> +0x174 ImageFileName : [16] “svchost.exe”
>>> +0x1f8 Vm :
>>> +0x020 VmWorkingSetList :
>>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>>> +0x174 ImageFileName : [16] “svchost.exe”
>>> +0x1f8 Vm :
>>> +0x020 VmWorkingSetList :
>>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>>> +0x174 ImageFileName : [16] “svchost.exe”
>>> +0x1f8 Vm :
>>> +0x020 VmWorkingSetList :
>>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>>> +0x174 ImageFileName : [16] “svchost.exe”
>>> +0x1f8 Vm :
>>> +0x020 VmWorkingSetList :
>>> +0x014 Wsle : 0xc0883cfc _MMWSLE
>>>
>>>
>>> On 5/17/12, xxxxx@alice.it wrote:
>>>>> the constant that i used 0xc0883cfc may be different for you…
>>>>
>>>> Same value also in my case
>>>>
>>>> lkd> dd c0883000
>>>> c0883000 00000000 00000912 00000010 00000ca7
>>>> c0883010 00000007 c0883cfc 00000cc0 000003cc
>>>> …
>>>>
>>>>> it is at Default working set list +0x14…
>>>>
>>>> what/which is the " Default working set list" ? is it related to the
>>>> current
>>>> “implicit” process ?
>>>>
>>>> —
>>>> 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
>>>>
>>>
>>
></stdio.h></windows.h>

> the (firstfree)0x912 @ + 0x04 in the display etc

thanks raj for you help…excuse me but what do you mean with "(firstfree)0x912 @ + 0x04 ?

kd> dd c0883000
c0883000 00000000 00000912

the 912 @ c0883004 in your post indicated FirstFree is what i meant

lkd> dt nt!_mmwsl
+0x000 Quota : Uint4B
+0x004 FirstFree : Uint4B

if you are working in lkd this entry will keep on changing every time
you issue any command
as lkd uses a snap shot and the snap shot is not frozen view like
kernel debugger

in kernel debugger uinless you hit go and break back the output will
be constant
as it is a frozen view of os

On 5/18/12, xxxxx@alice.it wrote:
>> the (firstfree)0x912 @ + 0x04 in the display etc
>
> thanks raj for you help…excuse me but what do you mean with
> "(firstfree)0x912 @ + 0x04 ?
>
>
> —
> 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
>

For Win XP client the only option to perform kernel debugging freezing the OS is remote debugging using serial port on the target PC ?

Ps how can the target PC control the serial port is the OS itself is frozen ?

Yes, the OS is frozen. The kernel uses Kdcom.dll in order to send and receive stuff to/from serial port. No drivers are involved in the communication. Handling communication over serial port is easy, and pretty standard since the serial port was born.

yes os is frozen

unless you have to tinker with real hardware or deal with vm aware malwares

you can simulate a good kernel debugging scenario by

setting up a virtual machine and kernel debugging that virtual machine
over serial in a single pc

your laptop should be more that sufficient if it has about a gb of ram
and about 5 gb of free space for xp

i started writing a short page about setting up vpc 2007 and windbg
but havent finished it :slight_smile:

https://sites.google.com/site/ulongbluff/bluffing-with-windbg-virtual-pc-and-kerneldebugging

On 5/19/12, xxxxx@volny.cz wrote:
> Yes, the OS is frozen. The kernel uses Kdcom.dll in order to send and
> receive stuff to/from serial port. No drivers are involved in the
> communication. Handling communication over serial port is easy, and pretty
> standard since the serial port was born.
>
> —
> 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
>

> Yes, the OS is frozen. The kernel uses Kdcom.dll in order to send and receive
stuff to/from serial port. No drivers are involved in the communication.

So, IIUC, Kdcom.dll runs only in user mode…in other words Kdcom.dll does not invoke - either directly or indirectly - any system call (kernel services)…

Does it make sense ?

No, but I can understand how you might conclude that from the ‘no drivers’
part.

There’s no ‘traditional’ drivers involved - kdcom.dll takes care of it
directly. This doesn’t pose any problems of contention et c. because one kd
claims a serial port, the rest of the system doesn’t use it.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@alice.it
Sent: Saturday, May 19, 2012 1:54 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] !wlse extension

Yes, the OS is frozen. The kernel uses Kdcom.dll in order to send and
receive
stuff to/from serial port. No drivers are involved in the communication.

So, IIUC, Kdcom.dll runs only in user mode…in other words Kdcom.dll does
not invoke - either directly or indirectly - any system call (kernel
services)…

Does it make sense ?


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