> Well Dr NewComer I Am Not Sure If Visual Studio Debugger Can handle
parsing
Working Set List Entries
in kernelmode
Pages in Both process are a simple one liner with VirtualAlloc Pasted
below only change is the sprintf_string process 1 has WsleTestOne
process 2 has WsleTestTwo
*****
OK, I was a bit confused from the first post, because it sounded like you
were sharing a page between two processes. This makes it clearer that you
have two independent processes each of which is allocating a private page.
****
int main(void)
{
PCHAR PageAllot = (PCHAR) VirtualAlloc(
NULL,
4096,
****
Generally, you should not assume pages are 4096 bytes; there’s an API that
reurns this value
*****
MEM_COMMIT | MEM_RESERVE,
PAGE_EXECUTE_READWRITE
);
if (PageAllot != 0 ) {
sprintf_s(
PageAllot,
200,
“WsleTestOne Alloted This Page @ %p\n”,
PageAllot
);
DebugBreak();
VirtualFree(
PageAllot,
0,
MEM_RELEASE
);
return 0;
}
return 1;
}and i want to break both these similar process in kernel debugger
simultaneously
*****
I have never tried to use a kernel debugger to handle int3 calls from user
space. The VS debugger works nicely for this purpose. But since you need
to be in the kernel to get the information you need, VS isn’t going to be
much help here. What will happen is that the first process to hit the
breakpoint enters windbg, and Windows stops. This means the second
process cannot run until you proceed from the breakpoint, at which point
the first process frees the memory.
It is an ugly hack, but perhaps putting a lengthy Sleep() call after the
breakpoint call will help.
joe
*****
and want to examine wsle
like below
kd> g
Break instruction exception - code 80000003 (first chance)
ntdll!DbgBreakPoint:
001b:7c90120e cc int 3
kd> .process /p /r
Implicit process is now ffb38ad8
.cache noforcedecodeptes done
Loading User Symbols
…
*** WARNING: Unable to verify checksum for WsleTestModOne.exe
kd> kbL
ChildEBP RetAddr Args to Child
0012ff6c 00401051 00350000 0012ffc0 004013a3 ntdll!DbgBreakPoint
0012ff78 004013a3 00000001 00332ea8 00332ef0 WsleTestModOne!main+0x41
0012ffc0 7c817067 00380036 00360037 7ffdc000
WsleTestModOne!__tmainCRTStartup+0xfb
0012fff0 00000000 004013fa 00000000 78746341
kernel32!BaseProcessStart+0x23kd> ?? ((((nt!_EPROCESS *)@$proc)->Vm).VmWorkingSetList)->Wsle->u1
union __unnamed
+0x000 VirtualAddress : 0xc0300203 Void
+0x000 Long : 0xc0300203
+0x000 e1 : _MMWSLENTRYkd> .for( r $t0 =5d ; $t0<61;R $t0 = $t0+1) {da
(poi(0xc050369c+$t0*4)&0xfffff000) l40 }
00413000 “.}.”
7c814000 “torageOnILockBytes”
00350000 "WsleTestOne Alloted This Page @ "
00350020 “00350000.”
00251000 “”On 5/23/12, xxxxx@flounder.com wrote:
>> Visual Studio has supported multiprocess debugging for years. So I
>> would
>> suggest looking into that as a better solution. In my lab exercise, we
>> had
>> two programs writing to a shared page, and unless there was a breakpoint
>> set in the receiver, it would continue to run even while I was
>> single-stepping the sender.
>>
>> How are you “allocating” a page into both processes?
>> joe
>>
>>> Thanks Dr NewComer Your Comments are As usual quiet Right and i agree
>>> i should stop coding assembly styled C infact i posted the whole
>>> snippet a few posts above including declaration for PageAllot which
>>> incidentally was declared as LPVOID PageAllot;
>>>
>>> i dont know but i tried while (true) / i tried running the app in a
>>> usermode debugger and trapping it in kd but none of the things shows
>>> the newly alloted page in working set list
>>>
>>> let me clarify the whole purpose of the DEMO was to see the results of
>>> the pages allocated by two executables that has minor difference in
>>> them in any possible way (either by hook or crook)
>>>
>>> so basically the CONCEPT was to make two exes that each alloted a page
>>> wrote something to that page and broke into debugger using
>>> DebugBreak()
>>>
>>> now this posed a problem once the first app broke in KD i couldn’t
>>> execute the second app
>>> so to bypass this problem i assembled an infinite jump let it spin and
>>> executed the second app which again broke in KD
>>>
>>> now i could examine both of them side by side in KD
>>>
>>> so after the DEMO i was trying to improve the strategy
>>>
>>> so i posed the question to the group asking if there is a better way
>>> to break two apps simultaneously in any way possible exactly like
>>> DebugBreak breaks in KD
>>>
>>> while i did it with asm _emit { 0xeb 0xfe } inline in code
>>> instead of DebugBreak()
>>>
>>> or some while (true)
>>>
>>> or when run in a local debugger and redirecting the output to kd (viz
>>> ntsd -d “mytestapp.exe”
>>>
>>> the working set list (dt nt!_MMWSL <_______________> ->wsle) donot
>>> show the PAGE that was alloted
>>>
>>> they were visible as posted in an earlier post only immediatly after
>>> DebugBreak In kernel
>>>
>>> possibly because of BalanceSetManagers background operation or some
>>> thing which i am not sure of either terminology or logic
>>>
>>>
>>>
>>> just for the sake of referance i am pasting the earlier posts content
>>>
>>>
>>> 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+($t04))&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/21/12, xxxxx@alice.it
>>> wrote:
>>>>> compile these few lines into two executables by making a difference
>>>>> between them as follows
>>>>> 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
>>>>
>>>> I compiled and run the two executables (compiled using VC 10) on my
>>>> Win
>>>> XP
>>>> laptop…however they break in user windbg debugger (not lkd or
>>>> kd)…
>>>>
>>>> Can you give me some help ??
>>>>
>>>>
>>>>
>>>> —
>>>> WINDBG is sponsored by OSR
>>>>
>>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>>> http://www.osr.com/seminars
>>>>
>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>
>>>
>>> —
>>> WINDBG is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>>
>>
>> —
>> WINDBG is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> —
> 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>
