Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Developing Minifilters | 24 May 2021 | Live, Online |
Writing WDF Drivers | 14 June 2021 | Live, Online |
Internals & Software Drivers | 2 August 2021 | Live, Online |
Kernel Debugging | 27 Sept 2021 | Live, Online |
Comments
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, [email protected] <[email protected]> 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
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 <[email protected]> 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, [email protected] <[email protected]> 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
>>
>
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 ?
@#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, [email protected] <[email protected]> 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
>
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 ?
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 <[email protected]> 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, [email protected] <[email protected]> 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
>>
>
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 <[email protected]> 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 <[email protected]> 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, [email protected] <[email protected]> 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
>>>
>>
>
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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, [email protected] <[email protected]> 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
>>>>
>>>
>>
>
thanks raj for you help....excuse me but what do you mean with "(firstfree)0x912 @ + 0x04 ?
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, [email protected] <[email protected]> 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
>
Ps how can the target PC control the serial port is the OS itself 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
https://sites.google.com/site/ulongbluff/bluffing-with-windbg-virtual-pc-and-kerneldebugging
On 5/19/12, [email protected] <[email protected]> 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
>
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 ?
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: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
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