.childdbg question

this may be a dumb question

i do file->open executable -> checkmark Debug Child Process Also -> and open
a executable

i confirm if it will debug the child or not with

0:000> .childdbg
Processes created by the current process will be debugged

do g thrice to land in child that was spawned by the debugee

*** WARNING: Unable to verify checksum for image00400000
*** ERROR: Module load completed but symbols could not be loaded for
image00400000
image00400000+0x1000:
00401000 cc int 3

00401000 cc int 3
00401001 006800 add byte ptr [eax],ch
00401004 304000 xor byte ptr [eax],al
00401007 6819304000 push offset image00400000+0x3019 (00403019)

now am i forced to change the int 3 back to the original opcode that was
there manually ??

before starting to trace ??

1:001> r eip
eip=00401000
1:001> t
eax=00000000 ebx=7ffdf000 ecx=0012ffb0 edx=7c90eb94 esi=00000034
edi=7c91b686
eip=00401001 esp=0012ffc4 ebp=0012fff0 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
image00400000+0x1001:
00401001 006800 add byte ptr [eax],ch
ds:0023:00000000=??

gh gn etc dont seem to avoid the access violation because it is trying to
execute bogus line at 401001

well editing with eb does the job but i need to remember what was the opcode
thats why the above question

1:001> u
image00400000+0x1000:
00401000 cc int 3
00401001 006800 add byte ptr [eax],ch
00401004 304000 xor byte ptr [eax],al
00401007 6819304000 push offset image00400000+0x3019 (00403019)
0040100c 6a00 push 0
0040100e e807000000 call image00400000+0x101a (0040101a)
00401013 6a00 push 0
00401015 e806000000 call image00400000+0x1020 (00401020)
1:001> eb eip 0x6a

1:001> u 401000
image00400000+0x1000:
00401000 6a00 push 0
00401002 6800304000 push offset image00400000+0x3000 (00403000)
00401007 6819304000 push offset image00400000+0x3019 (00403019)
0040100c 6a00 push 0
0040100e e807000000 call image00400000+0x101a (0040101a)
00401013 6a00 push 0
00401015 e806000000 call image00400000+0x1020 (00401020)
0040101a ff2508204000 jmp dword ptr [image00400000+0x2008 (00402008)]

What processes are you debugging? What breakpoints do you have set?

Child debugging does not lead to code stream modifications, this is
something else.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Sunday, August 06, 2006 12:01 PM
To: Kernel Debugging Interest List
Subject: [windbg] .childdbg question

this may be a dumb question

i do file->open executable -> checkmark Debug Child Process Also -> and
open a executable

i confirm if it will debug the child or not with

0:000> .childdbg
Processes created by the current process will be debugged

do g thrice to land in child that was spawned by the debugee

*** WARNING: Unable to verify checksum for image00400000
*** ERROR: Module load completed but symbols could not be loaded for
image00400000
image00400000+0x1000:
00401000 cc int 3

00401000 cc int 3
00401001 006800 add byte ptr [eax],ch
00401004 304000 xor byte ptr [eax],al
00401007 6819304000 push offset image00400000+0x3019 (00403019)

now am i forced to change the int 3 back to the original opcode that was
there manually ??

before starting to trace ??

1:001> r eip
eip=00401000
1:001> t
eax=00000000 ebx=7ffdf000 ecx=0012ffb0 edx=7c90eb94 esi=00000034
edi=7c91b686
eip=00401001 esp=0012ffc4 ebp=0012fff0 iopl=0 nv up ei pl zr na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
image00400000+0x1001:
00401001 006800 add byte ptr [eax],ch
ds:0023:00000000=??

gh gn etc dont seem to avoid the access violation because it is trying
to execute bogus line at 401001

— You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

On 8/7/06, Drew Bliss wrote:

> What processes are you debugging? What breakpoints do you have set?
>
> Child debugging does not lead to code stream modifications, this is
> something else.
>

the process is a simple one line code that is
LoadModule(modulename,&lparms);

yep it runs without problems when double clicked the exe in modulename
argument is again a simple MessageBox()

i have not set any breakpoints

i just do file-> open executable
select that debug child also check box

hit g twice and i land in the debugeees child

but it has an embedded int3 at start

thats why i asked

here is the output

CommandLine: D:\Borland\odbg110\odbg110\Bin\opd.exe
Symbol search path is: SRVD:\Borland\odbg110\symbols
http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 00412000 opd.exe
ModLoad: 7c900000 7c9b0000 ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77d40000 77dd0000 C:\WINDOWS\system32\USER32.DLL
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
(2f0.4c4): Break instruction exception - code 80000003 (first chance)
eax=00241eb4 ebx=7ffdd000 ecx=00000007 edx=00000080 esi=00241f48
edi=00241eb4
eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na po
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3

0:000> g <------------------------
ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.DLL
ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll
Symbol search path is: SRVD:\Borland\odbg110\symbols
http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 00404000 image00400000
ModLoad: 7c900000 7c9b0000 ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77d40000 77dd0000 C:\WINDOWS\system32\user32.dll
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll

(180.1b0): Break instruction exception - code 80000003 (first chance)
eax=00241eb4 ebx=7ffdc000 ecx=00000007 edx=00000080 esi=00241f48
edi=00241eb4
eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na po
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3

1:001> g <------------------ second g

(180.1b0): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=7ffdc000 ecx=0012ffb0 edx=7c90eb94 esi=0000002b
edi=7c91b686
eip=00401000 esp=0012ffc4 ebp=0012fff0 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
WARNING: Unable to verify checksum for image00400000
ERROR: Module load completed but symbols could not be loaded for
image00400000
image00400000+0x1000:
00401000 cc int 3
1:001> u
image00400000+0x1000:
00401000 cc int 3
00401001 006800 add byte ptr [eax],ch
00401004 304000 xor byte ptr [eax],al
00401007 6819304000 push offset image00400000+0x3019 (00403019)
0040100c 6a00 push 0
0040100e e807000000 call image00400000+0x101a (0040101a)
00401013 6a00 push 0
00401015 e806000000 call image00400000+0x1020 (00401020)

1:001> da 403019 <-------------yep the string is right
00403019 “Win32 Assembly is Great!”
1:001> u 40101a L1
image00400000+0x101a:
0040101a ff2508204000 jmp dword ptr [image00400000+0x2008 (00402008)]
1:001> .printf “%y\n”,poi(402008)
user32!MessageBoxA (77d804ea) <------------- yes its just a msgbox
iczelions tut 02

code of my one liner may be shabby wrong was just a test
yes i know i should use CreateProcess
i havent tested with a CreateProcess
will make a test program with CreateProcess later and will post if it
worked till then this is what i have to show

#include <windows.h>
# pragma argsused

typedef struct _CMDSHOW
{
WORD fp;
WORD sp;
} cmdshow;

typedef struct tagLOADPARMS32
{
LPSTR lpEnvAddress; // address of environment strings
LPSTR lpCmdLine; // address of command line
LPSTR lpCmdShow; // how to show new program
DWORD dwReserved; // must be zero
} LOADPARMS32;

WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR
lpCmdLine,int nCmdShow)
{
char modulename = {“msgbox.exe”};
char lpcmdline[2]={0};

LOADPARMS32 lparms;
cmdshow cs;

cs.fp =2;
cs.sp =SW_SHOWNORMAL;

lparms.lpEnvAddress = 0;
lparms.lpCmdLine = lstrcpyn(lpcmdline,lpcmdline,sizeof(lpcmdline));
lparms.lpCmdShow = &cs;
lparms.dwReserved = 0;

LoadModule(modulename,&lparms);
MessageBox(NULL,“new proc is already here”, “LoadModule”,NULL);

return 1;
}

exe compiled with bcc5.5 freecommandlinetools

additional information that i encountered today

if i dont select debug child also

and just do file -> open executable on the above application

windbg just hangs with debugee is running message

ctrl+c does not break

and also hangs the pc (some thing like stuck somewhere in an infinite loop
deep in system and cant able to break out of it)

i am forced to hard reboot</windows.h>

The system does a break immediately after process initialization for
user-mode processes that are being debugged. You can just ‘g’ past it.
If you want to ignore this start the debugger with -g.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Monday, August 07, 2006 11:16 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] .childdbg question

On 8/7/06, Drew Bliss wrote:

What processes are you debugging? What breakpoints do you have
set?

Child debugging does not lead to code stream modifications, this
is something else.

the process is a simple one line code that is
LoadModule(modulename,&lparms);

yep it runs without problems when double clicked the exe in modulename
argument is again a simple MessageBox()

i have not set any breakpoints

i just do file-> open executable
select that debug child also check box

hit g twice and i land in the debugeees child

but it has an embedded int3 at start

thats why i asked

here is the output

CommandLine: D:\Borland\odbg110\odbg110\Bin\opd.exe
Symbol search path is:
SRVD:\Borland\odbg110\symbolshttp://msdl.microsoft.com/download/symbol
s
Executable search path is:
ModLoad: 00400000 00412000 opd.exe
ModLoad: 7c900000 7c9b0000 ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77d40000 77dd0000 C:\WINDOWS\system32\USER32.DLL
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
(2f0.4c4): Break instruction exception - code 80000003 (first chance)
eax=00241eb4 ebx=7ffdd000 ecx=00000007 edx=00000080 esi=00241f48
edi=00241eb4
eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na
po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3

0:000> g <------------------------
ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.DLL
ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll
Symbol search path is: SRVD:\Borland\odbg110\symbols
http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 00404000 image00400000
ModLoad: 7c900000 7c9b0000 ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77d40000 77dd0000 C:\WINDOWS\system32\user32.dll
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll

(180.1b0): Break instruction exception - code 80000003 (first chance)
eax=00241eb4 ebx=7ffdc000 ecx=00000007 edx=00000080 esi=00241f48
edi=00241eb4
eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na
po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3

1:001> g <------------------ second g

(180.1b0): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=7ffdc000 ecx=0012ffb0 edx=7c90eb94 esi=0000002b
edi=7c91b686
eip=00401000 esp=0012ffc4 ebp=0012fff0 iopl=0 nv up ei pl zr na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
WARNING: Unable to verify checksum for image00400000
ERROR: Module load completed but symbols could not be loaded for
image00400000
image00400000+0x1000:
00401000 cc int 3
1:001> u
image00400000+0x1000:
00401000 cc int 3
00401001 006800 add byte ptr [eax],ch
00401004 304000 xor byte ptr [eax],al
00401007 6819304000 push offset image00400000+0x3019 (00403019)
0040100c 6a00 push 0
0040100e e807000000 call image00400000+0x101a (0040101a)
00401013 6a00 push 0
00401015 e806000000 call image00400000+0x1020 (00401020)

1:001> da 403019 <-------------yep the string is right
00403019 “Win32 Assembly is Great!”
1:001> u 40101a L1
image00400000+0x101a:
0040101a ff2508204000 jmp dword ptr [image00400000+0x2008
(00402008)]
1:001> .printf “%y\n”,poi(402008)
user32!MessageBoxA (77d804ea) <------------- yes its just a msgbox
iczelions tut 02

code of my one liner may be shabby wrong was just a test
yes i know i should use CreateProcess
i havent tested with a CreateProcess
will make a test program with CreateProcess later and will post if it
worked till then this is what i have to show

#include <windows.h>
# pragma argsused

typedef struct _CMDSHOW
{
WORD fp;
WORD sp;
} cmdshow;

typedef struct tagLOADPARMS32
{
LPSTR lpEnvAddress; // address of environment strings
LPSTR lpCmdLine; // address of command line
LPSTR lpCmdShow; // how to show new program
DWORD dwReserved; // must be zero
} LOADPARMS32;

WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR
lpCmdLine,int nCmdShow)
{
char modulename = {“msgbox.exe”};
char lpcmdline[2]={0};

LOADPARMS32 lparms;
cmdshow cs;

cs.fp =2;
cs.sp =SW_SHOWNORMAL;

lparms.lpEnvAddress = 0;
lparms.lpCmdLine = lstrcpyn(lpcmdline,lpcmdline,sizeof(lpcmdline));
lparms.lpCmdShow = &cs;
lparms.dwReserved = 0;

LoadModule(modulename,&lparms);
MessageBox(NULL,“new proc is already here”, “LoadModule”,NULL);

return 1;
}

exe compiled with bcc5.5 freecommandlinetools

additional information that i encountered today

if i dont select debug child also

and just do file -> open executable on the above application

windbg just hangs with debugee is running message

ctrl+c does not break

and also hangs the pc (some thing like stuck somewhere in an infinite
loop deep in system and cant able to break out of it)

i am forced to hard reboot

— You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</windows.h>

On 8/7/06, Drew Bliss wrote:
>
> The system does a break immediately after process initialization for
> user-mode processes that are being debugged. You can just ‘g’ past it. If
> you want to ignore this start the debugger with -g.
>

windbg started with -g

output

CommandLine: D:\Borland\odbg110\odbg110\Bin\opd.exe
Symbol search path is: SRVD:\Borland\odbg110\symbols
http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 00412000 opd.exe
ModLoad: 7c900000 7c9b0000 ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77d40000 77dd0000 C:\WINDOWS\system32\USER32.DLL
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.DLL
ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll
Symbol search path is: SRVD:\Borland\odbg110\symbols
http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 00404000 image00400000
ModLoad: 7c900000 7c9b0000 ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77d40000 77dd0000 C:\WINDOWS\system32\user32.dll
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
(1c0.128): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=7ffd4000 ecx=0012ffb0 edx=7c90eb94 esi=0000002b
edi=7c91b686
eip=00401000 esp=0012ffc4 ebp=0012fff0 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
WARNING: Unable to verify checksum for image00400000
ERROR: Module load completed but symbols could not be loaded for
image00400000
image00400000+0x1000:
00401000 cc int 3
1:001> u
image00400000+0x1000:
00401000 cc int 3 <--------------------- still has it :frowning:
00401001 006800 add byte ptr [eax],ch
00401004 304000 xor byte ptr [eax],al
00401007 6819304000 push offset image00400000+0x3019 (00403019)
0040100c 6a00 push 0
0040100e e807000000 call image00400000+0x101a (0040101a)
00401013 6a00 push 0
00401015 e806000000 call image00400000+0x1020 (00401020)

tlist /t for the present

cmd.exe (412) C:\WINDOWS\system32\cmd.exe
windbg.exe (1928) D:\Borland\odbg110\odbg110\Bin\opd.exe - WinDbg:
6.6.0007.5

opd.exe (2012)
msgbox.exe (448)
cmd.exe (588) C:\WINDOWS\system32\cmd.exe - tlist /t
tlist.exe (540)

-g looks to have worked, the opd initial break has been skipped. Your
other binary appears to have an embedded int 3 in it. If you look at
the executable file with a hex editor can you find the initial byte
sequence that maps to RVA 0x1000? Does it have the cc?


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Monday, August 07, 2006 11:31 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] .childdbg question

On 8/7/06, Drew Bliss wrote:

The system does a break immediately after process initialization
for user-mode processes that are being debugged. You can just ‘g’ past
it. If you want to ignore this start the debugger with -g.

windbg started with -g

output

CommandLine: D:\Borland\odbg110\odbg110\Bin\opd.exe
Symbol search path is:
SRVD:\Borland\odbg110\symbolshttp://msdl.microsoft.com/download/symbol
s
Executable search path is:
ModLoad: 00400000 00412000 opd.exe
ModLoad: 7c900000 7c9b0000 ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77d40000 77dd0000 C:\WINDOWS\system32\USER32.DLL
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.DLL
ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll
Symbol search path is: SRVD:\Borland\odbg110\symbols
http://msdl.microsoft.com/download/symbols
http:
Executable search path is:
ModLoad: 00400000 00404000 image00400000
ModLoad: 7c900000 7c9b0000 ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77d40000 77dd0000 C:\WINDOWS\system32\user32.dll
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
(1c0.128): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=7ffd4000 ecx=0012ffb0 edx=7c90eb94 esi=0000002b
edi=7c91b686
eip=00401000 esp=0012ffc4 ebp=0012fff0 iopl=0 nv up ei pl zr na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
WARNING: Unable to verify checksum for image00400000
ERROR: Module load completed but symbols could not be loaded for
image00400000
image00400000+0x1000:
00401000 cc int 3
1:001> u
image00400000+0x1000:
00401000 cc int 3 <--------------------- still has it
:frowning:
00401001 006800 add byte ptr [eax],ch
00401004 304000 xor byte ptr [eax],al
00401007 6819304000 push offset image00400000+0x3019 (00403019)
0040100c 6a00 push 0
0040100e e807000000 call image00400000+0x101a (0040101a)
00401013 6a00 push 0
00401015 e806000000 call image00400000+0x1020 (00401020)

— You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</http:>

I am really sorry to have wasted your time

yes it had an embedded int3 at start i must have miscopied
the executable while changing pcs

i was testing this in two pcs one with ollydbg and one with windbg
the one with ollydbg was running perfectly fine

I had an executable with an embedded int 3 to make it attach with ollydbg
just in time and i probably copied that to xp

sorry i will be more careful to actually double click and run these tests
before posting bogus reports

works fine i can break on both the executables entry

CommandLine: D:\Borland\odbg110\odbg110\Bin\opd.exe
Symbol search path is: SRV*D:\Borland\odbg110\symbols*
http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 00412000 opd.exe
ModLoad: 7c900000 7c9b0000 ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77d40000 77dd0000 C:\WINDOWS\system32\USER32.DLL
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
(534.1b0): Break instruction exception - code 80000003 (first chance)
eax=00241eb4 ebx=7ffd8000 ecx=00000007 edx=00000080 esi=00241f48
edi=00241eb4
eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na po
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3
0:000> bp 401000
*** WARNING: Unable to verify checksum for opd.exe
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
opd.exe -
0:000> g
Breakpoint 0 hit
eax=00000000 ebx=7ffd8000 ecx=0012ffb0 edx=7c90eb94 esi=0000006a
edi=00ecf6f0
eip=00401000 esp=0012ffc4 ebp=0012fff0 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
opd+0x1000:
00401000 eb10 jmp opd+0x1012 (00401012)
0:000> g
ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.DLL
ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll
Symbol search path is: SRV*D:\Borland\odbg110\symbols*
http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 00404000 image00400000
ModLoad: 7c900000 7c9b0000 ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77d40000 77dd0000 C:\WINDOWS\system32\user32.dll
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
(19c.190): Break instruction exception - code 80000003 (first chance)
eax=00241eb4 ebx=7ffde000 ecx=00000007 edx=00000080 esi=00241f48
edi=00241eb4
eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na po
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3
1:001> bp 401000
*** WARNING: Unable to verify checksum for image00400000
*** ERROR: Module load completed but symbols could not be loaded for
image00400000
1:001> g
Breakpoint 1 hit
eax=00000000 ebx=7ffde000 ecx=0012ffb0 edx=7c90eb94 esi=0000002b
edi=7c91b686
eip=00401000 esp=0012ffc4 ebp=0012fff0 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
image00400000+0x1000:
00401000 6a00 push 0

but i wonder why double clicking the exe with a hardcoded
0xcc doesnt make drwatson kick in with a
this program has performed an illegal operation
needs to be terminated dialogbox but just hangs without any explanation

I don’t know why this wouldn’t cause a Watson hit; I did a simple test
on Windows XP Service Pack 2 where I replaced the first byte of the
entry point of an executable with an int 3. When I ran the executable
the normal AeDebug process kicked in.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Monday, August 07, 2006 12:14 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] .childdbg question

works fine i can break on both the executables entry

CommandLine: D:\Borland\odbg110\odbg110\Bin\opd.exe
Symbol search path is:
SRV*D:\Borland\odbg110\symbols*http://msdl.microsoft.com/download/symbol
s
Executable search path is:
ModLoad: 00400000 00412000 opd.exe
ModLoad: 7c900000 7c9b0000 ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77d40000 77dd0000 C:\WINDOWS\system32\USER32.DLL
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
(534.1b0): Break instruction exception - code 80000003 (first chance)
eax=00241eb4 ebx=7ffd8000 ecx=00000007 edx=00000080 esi=00241f48
edi=00241eb4
eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na
po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3
0:000> bp 401000
*** WARNING: Unable to verify checksum for opd.exe
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for opd.exe -
0:000> g
Breakpoint 0 hit
eax=00000000 ebx=7ffd8000 ecx=0012ffb0 edx=7c90eb94 esi=0000006a
edi=00ecf6f0
eip=00401000 esp=0012ffc4 ebp=0012fff0 iopl=0 nv up ei pl zr na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
opd+0x1000:
00401000 eb10 jmp opd+0x1012 (00401012)
0:000> g
ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.DLL
ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll
Symbol search path is:
SRV*D:\Borland\odbg110\symbols*http://msdl.microsoft.com/download/symbol
s
Executable search path is:
ModLoad: 00400000 00404000 image00400000
ModLoad: 7c900000 7c9b0000 ntdll.dll
ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77d40000 77dd0000 C:\WINDOWS\system32\user32.dll
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
(19c.190): Break instruction exception - code 80000003 (first chance)
eax=00241eb4 ebx=7ffde000 ecx=00000007 edx=00000080 esi=00241f48
edi=00241eb4
eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na
po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3
1:001> bp 401000
*** WARNING: Unable to verify checksum for image00400000
*** ERROR: Module load completed but symbols could not be loaded for
image00400000
1:001> g
Breakpoint 1 hit
eax=00000000 ebx=7ffde000 ecx=0012ffb0 edx=7c90eb94 esi=0000002b
edi=7c91b686
eip=00401000 esp=0012ffc4 ebp=0012fff0 iopl=0 nv up ei pl zr na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
image00400000+0x1000:
00401000 6a00 push 0

but i wonder why double clicking the exe with a hardcoded
0xcc doesnt make drwatson kick in with a
this program has performed an illegal operation
needs to be terminated dialogbox but just hangs without any explanation

— You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Drew:
I don’t know why this wouldn’t cause a Watson hit; I did a simple test
on Windows XP Service Pack 2 where I replaced the first byte of the
entry point of an executable with an int 3. When I ran the executable
the normal AeDebug process kicked in.

yep it should kick in ollydbg can attach in other pc
so its just a guess i havent tested will test tonight

the xp had /debug switch in boot which i had left as it is from my local debugging
tests

probably that has got some thing to do with this hang
probably its waiting for some other debugger over in remote to kick in

will post after testing without /debug

If you booted /debug then an int 3 in user-mode for a process without a
UM debugger will break to kd (if no kd is currently connected the system
will wait) so removing /debug should fix the system freeze.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, August 08, 2006 12:53 AM
To: Kernel Debugging Interest List
Subject: RE:[windbg] .childdbg question

Drew:
I don’t know why this wouldn’t cause a Watson hit; I did a simple test
on Windows XP Service Pack 2 where I replaced the first byte of the
entry point of an executable with an int 3. When I ran the executable
the normal AeDebug process kicked in.

yep it should kick in ollydbg can attach in other pc so its just a guess
i havent tested will test tonight

the xp had /debug switch in boot which i had left as it is from my local
debugging tests

probably that has got some thing to do with this hang probably its
waiting for some other debugger over in remote to kick in

will post after testing without /debug


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

On 8/9/06, Drew Bliss wrote:
>
> If you booted /debug then an int 3 in user-mode for a process without a
> UM debugger will break to kd (if no kd is currently connected the system
> will wait) so removing /debug should fix the system freeze.

yes removing /debug made WER to kick in on that app

Exception Information 0x80000003 aka int3

so its always good to set to a AeDebugEntry so that it doesnt freeze
the system

and i can still have /debug switch left on and also terminate the
erring application

isnt it ?

what other problems i can face if i leave the /debug switch

on with a single id computer

bootcfg /debug on /id 1

If you boot /debug the kernel debugger will get hard breaks before any
UM code sees the exception at all. AeDebug kicks in later, so booting
/debug is the key here.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Tuesday, August 08, 2006 12:24 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] .childdbg question

On 8/9/06, Drew Bliss wrote:

If you booted /debug then an int 3 in user-mode for a process
without a
UM debugger will break to kd (if no kd is currently connected
the system
will wait) so removing /debug should fix the system freeze.

yes removing /debug made WER to kick in on that app

Exception Information 0x80000003 aka int3

so its always good to set to a AeDebugEntry so that it doesnt freeze
the system

and i can still have /debug switch left on and also terminate the
erring application

isnt it ?

what other problems i can face if i leave the /debug switch

on with a single id computer

bootcfg /debug on /id 1

— You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

This can also be changed with kdbgctrl.exe' on Srv03 and later, as far as I know (shipped with DTW) - I think the option is kdbgctrl -du’ to disable that particular behavior (breaking into kd on user mode breakpoints).


Ken Johnson (Skywing)
Windows SDK MVP

“Drew Bliss” wrote in message news:xxxxx@windbg…
If you boot /debug the kernel debugger will get hard breaks before any UM code sees the exception at all. AeDebug kicks in later, so booting /debug is the key here.

------------------------------------------------------------------------------
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Tuesday, August 08, 2006 12:24 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] .childdbg question

On 8/9/06, Drew Bliss wrote:
If you booted /debug then an int 3 in user-mode for a process without a
UM debugger will break to kd (if no kd is currently connected the system
will wait) so removing /debug should fix the system freeze.

yes removing /debug made WER to kick in on that app

Exception Information 0x80000003 aka int3

so its always good to set to a AeDebugEntry so that it doesnt freeze
the system

and i can still have /debug switch left on and also terminate the
erring application

isnt it ?

what other problems i can face if i leave the /debug switch

on with a single id computer

bootcfg /debug on /id 1

— You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To unsubscribe send a blank email to xxxxx@lists.osr.com

Drew:
If you boot /debug the kernel debugger will get hard breaks before any UM
code sees the exception at all. AeDebug kicks in later, so booting /debug
is the key here.

thanks i was about to try today obviously it would have resulted in a few
more freezes

btw this may be offtopic here but is there no way to grab the mdmp created
by wer without having to resort to some
extreme options ?

Microsoft (R) Windows Debugger Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\34D27.dmp]
User Mini Dump File: Only registers, stack and portions of memory are
available

Windows XP Version 2600 (Service Pack 2) UP Free x86 compatible
Debug session time: Wed Aug 9 23:13:54.000 2006 (GMT+6)
System Uptime: not available
Process Uptime: not available
Symbol search path is: SRV*D:\Borland\odbg110\symbols*
http://msdl.microsoft.com/download/symbols
Executable search path is:

Loading unloaded module list
.
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
eax=00880000 ebx=0012da84 ecx=00001000 edx=7c90eb94 esi=00000000
edi=7ffde000
eip=7c90eb94 esp=0012da5c ebp=0012daf8 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret
0:000> .excr
^ Syntax error in ‘.excr’
0:000> .ecxr
eax=00000000 ebx=7ffde000 ecx=0012ffb0 edx=7c90eb94 esi=00340038
edi=00390038
eip=00401000 esp=0012ffc4 ebp=0012fff0 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
*** WARNING: Unable to verify checksum for msgbox.exe
*** ERROR: Module load completed but symbols could not be loaded for
msgbox.exe
msgbox+0x1000:
00401000 cc int 3
windbg> .hh

On 8/9/06, Skywing wrote:
>
> This can also be changed with kdbgctrl.exe' on Srv03 and later, as far<br>&gt; as I know (shipped with DTW) - I think the option is kdbgctrl -du’ to
> disable that particular behavior (breaking into kd on user mode
> breakpoints).
>

yep i saw the -noumex in /debug switch but its only w2k3 and above as per
.hh

C:\Program Files\Debugging Tools for Windows>kdbgctrl.exe -cu
Unable to get Kernel debugger user exception enable, NTSTATUS 0xC0000003
{Invalid Parameter} The specified information class is not a valid
informat
ion class for the specified object.

C:\Program Files\Debugging Tools for Windows>

I’ve heard that there are some policy options for WER which allow you to
have reports queued somewhere on the system for later sending. The
dumps should then be sitting around on disk somewhere, but I’m not sure
that’s any more convenient than just getting the dump path from the WER
UI at the time of a problem.

I don’t know of any simple way to have reports stored in an obvious
place (as Dr. Watson used to do). I’m definitely not an expert on WER,
though.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Wednesday, August 09, 2006 10:58 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] .childdbg question

Drew:
If you boot /debug the kernel debugger will get hard breaks before any
UM code sees the exception at all. AeDebug kicks in later, so booting
/debug is the key here.

thanks i was about to try today obviously it would have resulted in a
few more freezes

btw this may be offtopic here but is there no way to grab the mdmp
created by wer without having to resort to some
extreme options ?

Microsoft (R) Windows Debugger Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\34D27.dmp]
User Mini Dump File: Only registers, stack and portions of memory are
available

Windows XP Version 2600 (Service Pack 2) UP Free x86 compatible
Debug session time: Wed Aug 9 23:13:54.000 2006 (GMT+6)
System Uptime: not available
Process Uptime: not available
Symbol search path is: SRV*D:\Borland\odbg110\symbols*
http://msdl.microsoft.com/download/symbols
Executable search path is:

Loading unloaded module list
.
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
eax=00880000 ebx=0012da84 ecx=00001000 edx=7c90eb94 esi=00000000
edi=7ffde000
eip=7c90eb94 esp=0012da5c ebp=0012daf8 iopl=0 nv up ei pl zr na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret
0:000> .excr
^ Syntax error in ‘.excr’
0:000> .ecxr
eax=00000000 ebx=7ffde000 ecx=0012ffb0 edx=7c90eb94 esi=00340038
edi=00390038
eip=00401000 esp=0012ffc4 ebp=0012fff0 iopl=0 nv up ei pl zr na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
*** WARNING: Unable to verify checksum for msgbox.exe
*** ERROR: Module load completed but symbols could not be loaded for
msgbox.exe
msgbox+0x1000:
00401000 cc int 3
windbg> .hh

On 8/9/06, Skywing wrote:

This can also be changed with kdbgctrl.exe' on Srv03 and later,<br>as far as I know (shipped with DTW) - I think the option is kdbgctrl
-du’ to disable that particular behavior (breaking into kd on user mode
breakpoints).

yep i saw the -noumex in /debug switch but its only w2k3 and above as
per .hh

C:\Program Files\Debugging Tools for Windows>kdbgctrl.exe -cu
Unable to get Kernel debugger user exception enable, NTSTATUS 0xC0000003
{Invalid Parameter} The specified information class is not a valid
informat
ion class for the specified object.

C:\Program Files\Debugging Tools for Windows>

— You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

On 8/10/06, Drew Bliss wrote:
>
> I’ve heard that there are some policy options for WER which allow you to
> have reports queued somewhere on the system for later sending. The dumps
> should then be sitting around on disk somewhere, but I’m not sure that’s any
> more convenient than just getting the dump path from the WER UI at the time
> of a problem.
>
> I don’t know of any simple way to have reports stored in an obvious place
> (as Dr. Watson used to do). I’m definitely not an expert on WER, though.
>

thanks again
:slight_smile: I will continue to pull the plug when i need to grab a dump instead of
looking around for all those policies that doesnt make sense
i would most likely be screwing it up setting those policies

the options at control panel->system-> error reporting doesnt
indicate there are any such options so itsnt obviously straight forward