Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

More Info on Driver Writing and Debugging


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/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

!wlse extension

Carlo_CianfaraniCarlo_Cianfarani Member Posts: 213
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 ?

Comments

  • raj_rraj_r Member - All Emails Posts: 987
    !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
    >
  • raj_rraj_r Member - All Emails Posts: 987
    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 <[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
    >>
    >
  • Carlo_CianfaraniCarlo_Cianfarani Member Posts: 213
    > 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 ?
  • raj_rraj_r Member - All Emails Posts: 987
    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
    >
  • Carlo_CianfaraniCarlo_Cianfarani Member Posts: 213
    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 ?
  • raj_rraj_r Member - All Emails Posts: 987
    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
    >>
    >
  • raj_rraj_r Member - All Emails Posts: 987
    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
    >>>
    >>
    >
  • raj_rraj_r Member - All Emails Posts: 987
    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 <[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
    >>>>
    >>>
    >>
    >
  • Carlo_CianfaraniCarlo_Cianfarani Member Posts: 213
    > the (firstfree)0x912 @ + 0x04 in the display etc

    thanks raj for you help....excuse me but what do you mean with "(firstfree)0x912 @ + 0x04 ?
  • raj_rraj_r Member - All Emails Posts: 987
    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, [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
    >
  • Carlo_CianfaraniCarlo_Cianfarani Member Posts: 213
    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 ?
  • Ladislav_ZezulaLadislav_Zezula Member - All Emails Posts: 65
    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.
  • raj_rraj_r Member - All Emails Posts: 987
    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 :)

    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
    >
  • Carlo_CianfaraniCarlo_Cianfarani Member Posts: 213
    > 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 ?
  • mmmm Member - All Emails Posts: 1,411
    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: [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
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

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