I was programing a small program in C++ and I had a memory bug (access violation)
For some reason I had the Event Logger services disabled. you know the annoying messagebox screaming at you “blabla.exe produced a error at 0x00CC1122”
and my program instead of crash quickly , Was re-launched for like 5 times (new PID each time)
But I wasn’t able to trace this behavior with windbg, at each time the exception handler seem to know about my debugger and he is simply continuing to jump at
the same location.
But without windbg or any debugger the process is really ‘relaunched’ !
I tried to trace it with immunity dbg and a anti debug plugin. but I failed to reproduce this (code relaunching) again
so I wonder if any of you have any idea why windows want to continue to relaunch my process and didn’t let him crash simply ?
I?m not really sure that I understand what you?re trying to impart.
However, UnhandledExceptionFilter only does the hard error / JIT debugger related logic if the process has no debug port, otherwise it doesn?t take the exception and lets the default (pass to debugger for a debugged process) action happen. You would need to patch out that check, or otherwise skip over it, if you want to debug UnhandledExceptionFilter.
S
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, January 09, 2009 6:26 PM
To: Kernel Debugging Interest List
Subject: [windbg] about the default exception handler and how to trace it (acting curiously)
Hello everyone
First let me explain myself.
I was programing a small program in C++ and I had a memory bug (access violation)
For some reason I had the Event Logger services disabled. you know the annoying messagebox screaming at you “blabla.exe produced a error at 0x00CC1122”
and my program instead of crash quickly , Was re-launched for like 5 times (new PID each time)
But I wasn?t able to trace this behavior with windbg, at each time the exception handler seem to know about my debugger and he is simply continuing to jump at
the same location.
But without windbg or any debugger the process is really ‘relaunched’ !
I tried to trace it with immunity dbg and a anti debug plugin. but I failed to reproduce this (code relaunching) again
so I wonder if any of you have any idea why windows want to continue to relaunch my process and didn?t let him crash simply ?
thanks for your time!
-Nico
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
LONG __stdcall unhandled( EXCEPTION_POINTERS* excep );
int main (void) {
DWORD a,b,c; SetUnhandledExceptionFilter(unhandled); printf (“relaunching this app after exception \n”); a= b = 2; c = a/b; printf(“first divide is %0x im going to divide by zero now for excepting\n”,c); a = 2; b = 0; c = a/b; printf (“this shouldnt be executing as result %0x is indeterminate\n”,c); return 1; }
printf (“shall i relaunch you %p\n”,excep); WinExec(“relaunched.exe”,SW_SHOWNORMAL); //obsolete do not use
return EXCEPTION_EXECUTE_HANDLER; }
relaunch>relaunched.exe relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 shall i relaunch you 0012FBB4 shall i relaunch you 0012F77C relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 shall i relaunch you 0012FBB4 shall i relaunch you 0012F77C relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 shall i relaunch you 0012FBB4 relaunching this app after exception shall i relaunch you 0012FBB4 shall i relaunch you 0012F77C first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4
outside debugger it will keep on relaunching inside debugger it will keep on jumping to div ebx
Log data Address Message 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero
0040118F DIV EBX 00401191 PUSH EAX ; /<%0x> = 2 00401192 PUSH relaunch.0040A191 ; |format = “this shouldnt be executing as result %0x is indeterminate ” 00401197 CALL relaunch. ___org_printf ; ___ org_printf
regards
raj_r
On 1/10/09, xxxxx@hotmail.com < xxxxx@hotmail.com> wrote: > > Hello everyone > > First let me explain myself. > > I was programing a small program in C++ and I had a memory bug (access > violation) > > For some reason I had the Event Logger services disabled. you know the > annoying messagebox screaming at you “blabla.exe produced a error at > 0x00CC1122” > > and my program instead of crash quickly , Was re-launched for like 5 times > (new PID each time) > > But I wasn’t able to trace this behavior with windbg, at each time the > exception handler seem to know about my debugger and he is simply > continuing to jump at > the same location. > > But without windbg or any debugger the process is really ‘relaunched’ ! > > I tried to trace it with immunity dbg and a anti debug plugin. but I > failed to reproduce this (code relaunching) again > > so I wonder if any of you have any idea why windows want to continue to > relaunch my process and didn’t let him crash simply ? > > > thanks for your time! > > -Nico > > > — > You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’ > > To unsubscribe send a blank email to xxxxx@lists.osr.com ></windows.h></stdio.h>
You can also use OllyDbg to debug your unhandled exception filter. But you
have to use OllyAdvanced Plugin with Ollydbg and check the Anti-Debug option
for SetUnhandledExceptionFilter.
Do a google search on ollydbg & OllyAdvanced Plugin.
Chandra
On Sat, Jan 10, 2009 at 5:07 PM, raj_r wrote:
> got some code like this running ? > > > #include <stdio.h> > #include <windows.h> > > LONG __stdcall unhandled( EXCEPTION_POINTERS* excep ); > > int main (void) > { > > DWORD a,b,c; > SetUnhandledExceptionFilter(unhandled); > printf (“relaunching this app after exception \n”); > a= b = 2; > c = a/b; > printf(“first divide is %0x im going to divide by zero now for > excepting\n”,c); > a = 2; > b = 0; > c = a/b; > printf (“this shouldnt be executing as result %0x is indeterminate\n”,c); > return 1; > } > > > > LONG__stdcall unhandled( EXCEPTION_POINTERS* excep ) > { > > printf (“shall i relaunch you %p\n”,excep); > WinExec(“relaunched.exe”,SW_SHOWNORMAL); //obsolete do not use > > return EXCEPTION_EXECUTE_HANDLER; > } > > > > relaunch>relaunched.exe > relaunching this app after exception > first divide is 1 im going to divide by zero now for excepting > shall i relaunch you 0012FBB4 > shall i relaunch you 0012FBB4 > shall i relaunch you 0012F77C > relaunching this app after exception > first divide is 1 im going to divide by zero now for excepting > shall i relaunch you 0012FBB4 > shall i relaunch you 0012FBB4 > shall i relaunch you 0012F77C > relaunching this app after exception > first divide is 1 im going to divide by zero now for excepting > shall i relaunch you 0012FBB4 > relaunching this app after exception > first divide is 1 im going to divide by zero now for excepting > shall i relaunch you 0012FBB4 > shall i relaunch you 0012FBB4 > relaunching this app after exception > shall i relaunch you 0012FBB4 > shall i relaunch you 0012F77C > first divide is 1 im going to divide by zero now for excepting > shall i relaunch you 0012FBB4 > > outside debugger it will keep on relaunching > inside debugger it will keep on jumping to div ebx > > Log data > Address Message > 0040118F Integer division by zero > 0040118F Integer division by zero > 0040118F Integer division by zero > 0040118F Integer division by zero > 0040118F Integer division by zero > 0040118F Integer division by zero > 0040118F Integer division by zero > 0040118F Integer division by zero > > > > 0040118F DIV EBX > 00401191 PUSH EAX ; /<%0x> = 2 > 00401192 PUSH relaunch.0040A191 ; |format = "this > shouldnt be executing as result %0x is indeterminate > " > 00401197 CALL relaunch. ___org_printf ; ___ org_printf > > > > regards > > raj_r > > > > > On 1/10/09, xxxxx@hotmail.com < > xxxxx@hotmail.com> wrote: > >> Hello everyone >> >> First let me explain myself. >> >> I was programing a small program in C++ and I had a memory bug (access >> violation) >> >> For some reason I had the Event Logger services disabled. you know the >> annoying messagebox screaming at you “blabla.exe produced a error at >> 0x00CC1122” >> >> and my program instead of crash quickly , Was re-launched for like 5 >> times (new PID each time) >> >> But I wasn’t able to trace this behavior with windbg, at each time the >> exception handler seem to know about my debugger and he is simply >> continuing to jump at >> the same location. >> >> But without windbg or any debugger the process is really ‘relaunched’ ! >> >> I tried to trace it with immunity dbg and a anti debug plugin. but I >> failed to reproduce this (code relaunching) again >> >> so I wonder if any of you have any idea why windows want to continue to >> relaunch my process and didn’t let him crash simply ? >> >> >> thanks for your time! >> >> -Nico >> >> >> — >> You are currently subscribed to windbg as: unknown lmsubst tag argument: >> ‘’ >> To unsubscribe send a blank email to xxxxx@lists.osr.com >> > > — You are currently subscribed to windbg as: xxxxx@gmail.com To > unsubscribe send a blank email to xxxxx@lists.osr.com</windows.h></stdio.h>
you dont need any plugin or whatever just a conditional break in windbg can
let you debug your unhandled exception filter
even when you are debugging it
i think ken already said so in one of the earlier post
ntdll!DbgBreakPoint:
7c901230 cc int 3
*0:000> bp ntdll!ZwQueryInformationProcess “.if (poi(esp+8) == 7) {gu;ed
(ebp-124) 0;bp suxehf!unhandled;g } .else {gc}”*
**
*all this line does is when debugport is queried on the said break it nulls
out the return of -1 *
*and you get to trace your unhandled exception filter stub*
0:000> g
(ee4.914): Integer divide-by-zero - code c0000094 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000002 ebx=00000000 ecx=00000002 edx=00000000 esi=0040a0b8
edi=00000000
eip=0040118f esp=0012ff88 ebp=0012ff8c iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010246
*** WARNING: Unable to verify checksum for suxehf.exe
suxehf!c2_0+0x3f:
0040118f f7f3 div eax,ebx
0:000> g
Breakpoint 1 hit
eax=004011a7 ebx=0012fbb4 ecx=0012f90c edx=7c90eb94 esi=c0000005
edi=00000000
eip=004011a7 esp=0012f930 ebp=0012fb9c iopl=0 nv up ei pl nz na po
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000202
*suxehf!unhandled:
*004011a7 55 push ebp
On 1/12/09, chandra97 97 wrote: > > You can also use OllyDbg to debug your unhandled exception filter. But you > have to use OllyAdvanced Plugin with Ollydbg and check the Anti-Debug option > for SetUnhandledExceptionFilter. > > Do a google search on ollydbg & OllyAdvanced Plugin. > > Chandra > > On Sat, Jan 10, 2009 at 5:07 PM, raj_r wrote: > >> got some code like this running ? >> >> >> #include <stdio.h> >> #include <windows.h> >> >> LONG __stdcall unhandled( EXCEPTION_POINTERS* excep ); >> >> int main (void) >> { >> >> DWORD a,b,c; >> SetUnhandledExceptionFilter(unhandled); >> printf (“relaunching this app after exception \n”); >> a= b = 2; >> c = a/b; >> printf(“first divide is %0x im going to divide by zero now for >> excepting\n”,c); >> a = 2; >> b = 0; >> c = a/b; >> printf (“this shouldnt be executing as result %0x is indeterminate\n”,c); >> return 1; >> } >> >> >> >> LONG__stdcall unhandled( EXCEPTION_POINTERS* excep ) >> { >> >> printf (“shall i relaunch you %p\n”,excep); >> WinExec(“relaunched.exe”,SW_SHOWNORMAL); //obsolete do not use >> >> return EXCEPTION_EXECUTE_HANDLER; >> } >> >> >> >> relaunch>relaunched.exe >> relaunching this app after exception >> first divide is 1 im going to divide by zero now for excepting >> shall i relaunch you 0012FBB4 >> shall i relaunch you 0012FBB4 >> shall i relaunch you 0012F77C >> relaunching this app after exception >> first divide is 1 im going to divide by zero now for excepting >> shall i relaunch you 0012FBB4 >> shall i relaunch you 0012FBB4 >> shall i relaunch you 0012F77C >> relaunching this app after exception >> first divide is 1 im going to divide by zero now for excepting >> shall i relaunch you 0012FBB4 >> relaunching this app after exception >> first divide is 1 im going to divide by zero now for excepting >> shall i relaunch you 0012FBB4 >> shall i relaunch you 0012FBB4 >> relaunching this app after exception >> shall i relaunch you 0012FBB4 >> shall i relaunch you 0012F77C >> first divide is 1 im going to divide by zero now for excepting >> shall i relaunch you 0012FBB4 >> >> outside debugger it will keep on relaunching >> inside debugger it will keep on jumping to div ebx >> >> Log data >> Address Message >> 0040118F Integer division by zero >> 0040118F Integer division by zero >> 0040118F Integer division by zero >> 0040118F Integer division by zero >> 0040118F Integer division by zero >> 0040118F Integer division by zero >> 0040118F Integer division by zero >> 0040118F Integer division by zero >> >> >> >> 0040118F DIV EBX >> 00401191 PUSH EAX ; /<%0x> = 2 >> 00401192 PUSH relaunch.0040A191 ; |format = "this >> shouldnt be executing as result %0x is indeterminate >> " >> 00401197 CALL relaunch. ___org_printf ; ___ org_printf >> >> >> >> regards >> >> raj_r >> >> >> >> >> On 1/10/09, xxxxx@hotmail.com < >> xxxxx@hotmail.com> wrote: >> >>> Hello everyone >>> >>> First let me explain myself. >>> >>> I was programing a small program in C++ and I had a memory bug (access >>> violation) >>> >>> For some reason I had the Event Logger services disabled. you know the >>> annoying messagebox screaming at you “blabla.exe produced a error at >>> 0x00CC1122” >>> >>> and my program instead of crash quickly , Was re-launched for like 5 >>> times (new PID each time) >>> >>> But I wasn’t able to trace this behavior with windbg, at each time the >>> exception handler seem to know about my debugger and he is simply >>> continuing to jump at >>> the same location. >>> >>> But without windbg or any debugger the process is really ‘relaunched’ ! >>> >>> I tried to trace it with immunity dbg and a anti debug plugin. but I >>> failed to reproduce this (code relaunching) again >>> >>> so I wonder if any of you have any idea why windows want to continue to >>> relaunch my process and didn’t let him crash simply ? >>> >>> >>> thanks for your time! >>> >>> -Nico >>> >>> >>> — >>> You are currently subscribed to windbg as: unknown lmsubst tag argument: >>> ‘’ >>> >>> To unsubscribe send a blank email to xxxxx@lists.osr.com >>> >> >> — You are currently subscribed to windbg as: xxxxx@gmail.com To >> unsubscribe send a blank email to xxxxx@lists.osr.com > > > — You are currently subscribed to windbg as: unknown lmsubst tag > argument: ‘’ To unsubscribe send a blank email to > xxxxx@lists.osr.com</windows.h></stdio.h>
Better to just write through the out param, or you’ll corrupt the stack should anyone else issue the call.
? S
From: raj_r Sent: Tuesday, January 13, 2009 11:21 To: Kernel Debugging Interest List Subject: Re: [windbg] about the default exception handler and how to trace it (acting curiously)
you dont need any plugin or whatever just a conditional break in windbg can let you debug your unhandled exception filter even when you are debugging it i think ken already said so in one of the earlier post
ntdll!DbgBreakPoint: 7c901230 cc int 3 0:000> bp ntdll!ZwQueryInformationProcess “.if (poi(esp+8) == 7) {gu;ed (ebp-124) 0;bp suxehf!unhandled;g } .else {gc}”
all this line does is when debugport is queried on the said break it nulls out the return of -1
and you get to trace your unhandled exception filter stub
0:000> g (ee4.914): Integer divide-by-zero - code c0000094 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000002 ebx=00000000 ecx=00000002 edx=00000000 esi=0040a0b8 edi=00000000 eip=0040118f esp=0012ff88 ebp=0012ff8c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 *** WARNING: Unable to verify checksum for suxehf.exe suxehf!c2_0+0x3f: 0040118f f7f3 div eax,ebx 0:000> g Breakpoint 1 hit eax=004011a7 ebx=0012fbb4 ecx=0012f90c edx=7c90eb94 esi=c0000005 edi=00000000 eip=004011a7 esp=0012f930 ebp=0012fb9c iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 suxehf!unhandled: 004011a7 55 push ebp
On 1/12/09, chandra97 97 > wrote: You can also use OllyDbg to debug your unhandled exception filter. But you have to use OllyAdvanced Plugin with Ollydbg and check the Anti-Debug option for SetUnhandledExceptionFilter.
Do a google search on ollydbg & OllyAdvanced Plugin.
Chandra
On Sat, Jan 10, 2009 at 5:07 PM, raj_r > wrote: got some code like this running ?
#include <stdio.h> #include <windows.h>
LONG __stdcall unhandled( EXCEPTION_POINTERS* excep );
int main (void) {
DWORD a,b,c; SetUnhandledExceptionFilter(unhandled); printf (“relaunching this app after exception \n”); a= b = 2; c = a/b; printf(“first divide is %0x im going to divide by zero now for excepting\n”,c); a = 2; b = 0; c = a/b; printf (“this shouldnt be executing as result %0x is indeterminate\n”,c); return 1; }
printf (“shall i relaunch you %p\n”,excep); WinExec(“relaunched.exe”,SW_SHOWNORMAL); //obsolete do not use
return EXCEPTION_EXECUTE_HANDLER; }
relaunch>relaunched.exe relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 shall i relaunch you 0012FBB4 shall i relaunch you 0012F77C relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 shall i relaunch you 0012FBB4 shall i relaunch you 0012F77C relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 shall i relaunch you 0012FBB4 relaunching this app after exception shall i relaunch you 0012FBB4 shall i relaunch you 0012F77C first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4
outside debugger it will keep on relaunching inside debugger it will keep on jumping to div ebx
Log data Address Message 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero
0040118F DIV EBX 00401191 PUSH EAX ; /<%0x> = 2 00401192 PUSH relaunch.0040A191 ; |format = “this shouldnt be executing as result %0x is indeterminate ” 00401197 CALL relaunch. ___org_printf ; ___ org_printf
I was programing a small program in C++ and I had a memory bug (access violation)
For some reason I had the Event Logger services disabled. you know the annoying messagebox screaming at you “blabla.exe produced a error at 0x00CC1122”
and my program instead of crash quickly , Was re-launched for like 5 times (new PID each time)
But I wasn’t able to trace this behavior with windbg, at each time the exception handler seem to know about my debugger and he is simply continuing to jump at the same location.
But without windbg or any debugger the process is really ‘relaunched’ !
I tried to trace it with immunity dbg and a anti debug plugin. but I failed to reproduce this (code relaunching) again
so I wonder if any of you have any idea why windows want to continue to relaunch my process and didn’t let him crash simply ?
thanks for your time!
-Nico
— You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
— You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.commailto:xxxxx
— You are currently subscribed to windbg as: xxxxx@valhallalegends.com To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></windows.h></stdio.h>
On 1/14/09, Skywing wrote: > > Better to just write through the out param, or you’ll corrupt the stack > should anyone else issue the call. >
sorry i did not understand what do you mean by out param you mean i should have used some thing else instead of (ebp -124) (ebp-0x124) or poi(esp-0xc) seems to be the only two options after gu
if i have to get the address of unhandled exception filter then i would need to device some way to emulate rtldecodepointer giving it
7C8833AC kernel32.BasepCurrentTopLevelFilter DB 9E BE 45 ۞?E value
thanks and regards
raj_r
? S > > ------------------------------ > From: raj_r > Sent: Tuesday, January 13, 2009 11:21 > To: Kernel Debugging Interest List > Subject: Re: [windbg] about the default exception handler and how to trace > it (acting curiously) > > you dont need any plugin or whatever just a conditional break in windbg > can let you debug your unhandled exception filter > even when you are debugging it > i think ken already said so in one of the earlier post > > ntdll!DbgBreakPoint: > 7c901230 cc int 3 > 0:000> bp ntdll!ZwQueryInformationProcess “.if (poi(esp+8) == 7) {gu;ed > (ebp-124) 0;bp suxehf!unhandled;g } .else {gc}” > * > all this line does is when debugport is queried on the said break it > nulls out the return of -1 > > and you get to trace your unhandled exception filter stub > > 0:000> g > (ee4.914): Integer divide-by-zero - code c0000094 (first chance) > First chance exceptions are reported before any exception handling. > This exception may be expected and handled. > eax=00000002 ebx=00000000 ecx=00000002 edx=00000000 esi=0040a0b8 > edi=00000000 > eip=0040118f esp=0012ff88 ebp=0012ff8c iopl=0 nv up ei pl zr na pe > nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00010246 > WARNING: Unable to verify checksum for suxehf.exe > suxehf!c2_0+0x3f: > 0040118f f7f3 div eax,ebx > 0:000> g > Breakpoint 1 hit > eax=004011a7 ebx=0012fbb4 ecx=0012f90c edx=7c90eb94 esi=c0000005 > edi=00000000 > eip=004011a7 esp=0012f930 ebp=0012fb9c iopl=0 nv up ei pl nz na po > nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 > efl=00000202 > suxehf!unhandled: > 004011a7 55 push ebp > > > > > On 1/12/09, chandra97 97 wrote: >> >> You can also use OllyDbg to debug your unhandled exception filter. But you >> have to use OllyAdvanced Plugin with Ollydbg and check the Anti-Debug option >> for SetUnhandledExceptionFilter. >> >> Do a google search on ollydbg & OllyAdvanced Plugin. >> >> Chandra >> >> On Sat, Jan 10, 2009 at 5:07 PM, raj_r wrote: >> >>> got some code like this running ? >>> >>> >>> #include <stdio.h> >>> #include <windows.h> >>> >>> LONG __stdcall unhandled( EXCEPTION_POINTERS excep ); >>> >>> int main (void) >>> { >>> >>> DWORD a,b,c; >>> SetUnhandledExceptionFilter(unhandled); >>> printf (“relaunching this app after exception \n”); >>> a= b = 2; >>> c = a/b; >>> printf(“first divide is %0x im going to divide by zero now for >>> excepting\n”,c); >>> a = 2; >>> b = 0; >>> c = a/b; >>> printf (“this shouldnt be executing as result %0x is >>> indeterminate\n”,c); >>> return 1; >>> } >>> >>> >>> >>> LONG__stdcall unhandled( EXCEPTION_POINTERS excep ) >>> { >>> >>> printf (“shall i relaunch you %p\n”,excep); >>> WinExec(“relaunched.exe”,SW_SHOWNORMAL); //obsolete do not use >>> >>> return EXCEPTION_EXECUTE_HANDLER; >>> } >>> >>> >>> >>> relaunch>relaunched.exe >>> relaunching this app after exception >>> first divide is 1 im going to divide by zero now for excepting >>> shall i relaunch you 0012FBB4 >>> shall i relaunch you 0012FBB4 >>> shall i relaunch you 0012F77C >>> relaunching this app after exception >>> first divide is 1 im going to divide by zero now for excepting >>> shall i relaunch you 0012FBB4 >>> shall i relaunch you 0012FBB4 >>> shall i relaunch you 0012F77C >>> relaunching this app after exception >>> first divide is 1 im going to divide by zero now for excepting >>> shall i relaunch you 0012FBB4 >>> relaunching this app after exception >>> first divide is 1 im going to divide by zero now for excepting >>> shall i relaunch you 0012FBB4 >>> shall i relaunch you 0012FBB4 >>> relaunching this app after exception >>> shall i relaunch you 0012FBB4 >>> shall i relaunch you 0012F77C >>> first divide is 1 im going to divide by zero now for excepting >>> shall i relaunch you 0012FBB4 >>> >>> outside debugger it will keep on relaunching >>> inside debugger it will keep on jumping to div ebx >>> >>> Log data >>> Address Message >>> 0040118F Integer division by zero >>> 0040118F Integer division by zero >>> 0040118F Integer division by zero >>> 0040118F Integer division by zero >>> 0040118F Integer division by zero >>> 0040118F Integer division by zero >>> 0040118F Integer division by zero >>> 0040118F Integer division by zero >>> >>> >>> >>> 0040118F DIV EBX >>> 00401191 PUSH EAX ; /<%0x> = 2 >>> 00401192 PUSH relaunch.0040A191 ; |format = "this >>> shouldnt be executing as result %0x is indeterminate >>> " >>> 00401197 CALL relaunch. ___org_printf ; ___ org_printf >>> >>> >>> >>> regards >>> >>> raj_r >>> >>> >>> >>> >>> On 1/10/09, xxxxx@hotmail.com < >>> xxxxx@hotmail.com> wrote: >>> >>>> Hello everyone >>>> >>>> First let me explain myself. >>>> >>>> I was programing a small program in C++ and I had a memory bug (access >>>> violation) >>>> >>>> For some reason I had the Event Logger services disabled. you know the >>>> annoying messagebox screaming at you “blabla.exe produced a error at >>>> 0x00CC1122” >>>> >>>> and my program instead of crash quickly , Was re-launched for like 5 >>>> times (new PID each time) >>>> >>>> But I wasn’t able to trace this behavior with windbg, at each time the >>>> exception handler seem to know about my debugger and he is simply >>>> continuing to jump at >>>> the same location. >>>> >>>> But without windbg or any debugger the process is really ‘relaunched’ ! >>>> >>>> I tried to trace it with immunity dbg and a anti debug plugin. but I >>>> failed to reproduce this (code relaunching) again >>>> >>>> so I wonder if any of you have any idea why windows want to continue to >>>> relaunch my process and didn’t let him crash simply ? >>>> >>>> >>>> thanks for your time! >>>> >>>> -Nico >>>> >>>> >>>> — >>>> You are currently subscribed to windbg as: unknown lmsubst tag argument: >>>> ‘’ >>>> >>>> To unsubscribe send a blank email to xxxxx@lists.osr.com >>>> >>> >>> — You are currently subscribed to windbg as: xxxxx@gmail.com To >>> unsubscribe send a blank email to xxxxx@lists.osr.com >> >> >> — You are currently subscribed to windbg as: unknown lmsubst tag >> argument: ‘’ To unsubscribe send a blank email to >> xxxxx@lists.osr.com > > > — You are currently subscribed to windbg as: xxxxx@valhallalegends.comTo unsubscribe send a blank email to > xxxxx@lists.osr.com > > — > You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’ > > To unsubscribe send a blank email to xxxxx@lists.osr.com ></windows.h></stdio.h>
You are reaching into the callers stack frame with that bp. It is specific to the stack layout of UnhandledExceptionFilter on your build. Another build or another function calling NtQueryInformationProcess will result in a corrupted stack.
A more generic approach to that would be to indirect through the pointer passed to the api to write the zero value instead of groveling around directly in the callers stack frame and hoping it’s the right caller.
? S
From: raj_r Sent: Tuesday, January 13, 2009 12:54 To: Kernel Debugging Interest List Subject: Re: [windbg] about the default exception handler and how to trace it (acting curiously)
On 1/14/09, Skywing > wrote: Better to just write through the out param, or you’ll corrupt the stack should anyone else issue the call.
sorry i did not understand what do you mean by out param you mean i should have used some thing else instead of (ebp -124) (ebp-0x124) or poi(esp-0xc) seems to be the only two options after gu
if i have to get the address of unhandled exception filter then i would need to device some way to emulate rtldecodepointer giving it
7C8833AC kernel32.BasepCurrentTopLevelFilter DB 9E BE 45 ۞?E
value
thanks and regards
raj_r
? S
________________________________ From: raj_r > Sent: Tuesday, January 13, 2009 11:21 To: Kernel Debugging Interest List > Subject: Re: [windbg] about the default exception handler and how to trace it (acting curiously)
you dont need any plugin or whatever just a conditional break in windbg can let you debug your unhandled exception filter even when you are debugging it i think ken already said so in one of the earlier post
ntdll!DbgBreakPoint: 7c901230 cc int 3 0:000> bp ntdll!ZwQueryInformationProcess “.if (poi(esp+8) == 7) {gu;ed (ebp-124) 0;bp suxehf!unhandled;g } .else {gc}”
all this line does is when debugport is queried on the said break it nulls out the return of -1
and you get to trace your unhandled exception filter stub
0:000> g (ee4.914): Integer divide-by-zero - code c0000094 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000002 ebx=00000000 ecx=00000002 edx=00000000 esi=0040a0b8 edi=00000000 eip=0040118f esp=0012ff88 ebp=0012ff8c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 *** WARNING: Unable to verify checksum for suxehf.exe suxehf!c2_0+0x3f: 0040118f f7f3 div eax,ebx 0:000> g Breakpoint 1 hit eax=004011a7 ebx=0012fbb4 ecx=0012f90c edx=7c90eb94 esi=c0000005 edi=00000000 eip=004011a7 esp=0012f930 ebp=0012fb9c iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 suxehf!unhandled: 004011a7 55 push ebp
On 1/12/09, chandra97 97 > wrote: You can also use OllyDbg to debug your unhandled exception filter. But you have to use OllyAdvanced Plugin with Ollydbg and check the Anti-Debug option for SetUnhandledExceptionFilter.
Do a google search on ollydbg & OllyAdvanced Plugin.
Chandra
On Sat, Jan 10, 2009 at 5:07 PM, raj_r > wrote: got some code like this running ?
DWORD a,b,c; SetUnhandledExceptionFilter(unhandled); printf (“relaunching this app after exception \n”); a= b = 2; c = a/b; printf(“first divide is %0x im going to divide by zero now for excepting\n”,c); a = 2; b = 0; c = a/b; printf (“this shouldnt be executing as result %0x is indeterminate\n”,c); return 1; }
LONG __stdcall unhandled( EXCEPTION_POINTERS* excep ) {
printf (“shall i relaunch you %p\n”,excep); WinExec(“relaunched.exe”,SW_SHOWNORMAL); //obsolete do not use
return EXCEPTION_EXECUTE_HANDLER; }
relaunch>relaunched.exe relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 shall i relaunch you 0012FBB4 shall i relaunch you 0012F77C relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 shall i relaunch you 0012FBB4 shall i relaunch you 0012F77C relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 shall i relaunch you 0012FBB4 relaunching this app after exception shall i relaunch you 0012FBB4 shall i relaunch you 0012F77C first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4
outside debugger it will keep on relaunching inside debugger it will keep on jumping to div ebx
Log data Address Message 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero
0040118F DIV EBX 00401191 PUSH EAX ; /<%0x> = 2 00401192 PUSH relaunch.0040A191 ; |format = “this shouldnt be executing as result %0x is indeterminate ” 00401197 CALL relaunch.___org_printf ; ___org_printf
I was programing a small program in C++ and I had a memory bug (access violation)
For some reason I had the Event Logger services disabled. you know the annoying messagebox screaming at you “blabla.exe produced a error at 0x00CC1122”
and my program instead of crash quickly , Was re-launched for like 5 times (new PID each time)
But I wasn’t able to trace this behavior with windbg, at each time the exception handler seem to know about my debugger and he is simply continuing to jump at the same location.
But without windbg or any debugger the process is really ‘relaunched’ !
I tried to trace it with immunity dbg and a anti debug plugin. but I failed to reproduce this (code relaunching) again
so I wonder if any of you have any idea why windows want to continue to relaunch my process and didn’t let him crash simply ?
thanks for your time!
-Nico
— You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
— You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.commailto:xxxxx
— You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></windows.h></stdio.h>
advice if the conditinal bp statement below comes closer to the mark
bp ntdll!ZwQueryInformationProcess “.if (poi(esp+8) == 7) { r $t1 =
poi(esp+0xc);gu;? poi($t1);ed $t1 0;? poi($t1);bp suxehf!unhandled; } .else
{gc}”
0:000> bp ntdll!ZwQueryInformationProcess “.if (poi(esp+8) == 7) { r $t1 =
poi(esp+0xc);gu;? poi($t1);ed $t1 0;? poi($t1);bp suxehf!unhandled; } .else
{gc}”
0:000> bl
0 e 7c90e01b 0001 (0001) 0:**** ntdll!NtQueryInformationProcess “.if
(poi(esp+8) == 7) { r $t1 = poi(esp+0xc);gu;? poi($t1);ed $t1 0;?
poi($t1);bp suxehf!unhandled; } .else {gc}”
0:000> g
(b6c.b74): Integer divide-by-zero - code c0000094 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000002 ebx=00000000 ecx=00000002 edx=00000000 esi=0040a0b8
edi=00000000
eip=0040118f esp=0012ff88 ebp=0012ff8c iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010246
*** WARNING: Unable to verify checksum for suxehf.exe
suxehf!c2_0+0x3f:
0040118f f7f3 div eax,ebx
0:000> gn
Evaluate expression: -1 = ffffffff
Evaluate expression: 0 = 00000000
eax=00000000 ebx=0012fbb4 ecx=0012f91c edx=7c90eb94 esi=c0000005
edi=00000000
eip=7c862c17 esp=0012f938 ebp=0012fb9c iopl=0 nv up ei ng nz na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000286
kernel32!UnhandledExceptionFilter+0x8d:
7c862c17 85c0 test eax,eax
0:000> g
Breakpoint 1 hit
eax=004011a7 ebx=0012fbb4 ecx=0012f90c edx=7c90eb94 esi=c0000005
edi=00000000
eip=004011a7 esp=0012f930 ebp=0012fb9c iopl=0 nv up ei pl nz na po
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000202
suxehf!unhandled:
004011a7 55 push ebp
On 1/14/09, Skywing wrote: > > You are reaching into the callers stack frame with that bp. It is specific > to the stack layout of UnhandledExceptionFilter on your build. Another build > or another function calling NtQueryInformationProcess will result in a > corrupted stack. > > A more generic approach to that would be to indirect through the pointer > passed to the api to write the zero value instead of groveling around > directly in the callers stack frame and hoping it’s the right caller. > > ? S > > ------------------------------ > From: raj_r > Sent: Tuesday, January 13, 2009 12:54 > To: Kernel Debugging Interest List > Subject: Re: [windbg] about the default exception handler and how to trace > it (acting curiously) > > > > On 1/14/09, Skywing wrote: >> >> Better to just write through the out param, or you’ll corrupt the stack >> should anyone else issue the call. >> > > sorry i did not understand what do you mean by out param > you mean i should have used some thing else instead of (ebp -124) > (ebp-0x124) or poi(esp-0xc) seems to be the only two options after gu > > if i have to get the address of unhandled exception filter then i would > need to device some way to emulate rtldecodepointer > giving it > > 7C8833AC kernel32.BasepCurrentTopLevelFilter DB 9E BE > 45 ۞?E > value > > thanks and regards > > raj_r > > > > > ? S >> >> ------------------------------ >> From: raj_r >> Sent: Tuesday, January 13, 2009 11:21 >> To: Kernel Debugging Interest List >> Subject: Re: [windbg] about the default exception handler and how to >> trace it (acting curiously) >> >> you dont need any plugin or whatever just a conditional break in windbg >> can let you debug your unhandled exception filter >> even when you are debugging it >> i think ken already said so in one of the earlier post >> >> ntdll!DbgBreakPoint: >> 7c901230 cc int 3 >> 0:000> bp ntdll!ZwQueryInformationProcess “.if (poi(esp+8) == 7) {gu;ed >> (ebp-124) 0;bp suxehf!unhandled;g } .else {gc}” >> * >> all this line does is when debugport is queried on the said break it >> nulls out the return of -1 >> >> and you get to trace your unhandled exception filter stub >> >> 0:000> g >> (ee4.914): Integer divide-by-zero - code c0000094 (first chance) >> First chance exceptions are reported before any exception handling. >> This exception may be expected and handled. >> eax=00000002 ebx=00000000 ecx=00000002 edx=00000000 esi=0040a0b8 >> edi=00000000 >> eip=0040118f esp=0012ff88 ebp=0012ff8c iopl=0 nv up ei pl zr na pe >> nc >> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >> efl=00010246 >> WARNING: Unable to verify checksum for suxehf.exe >> suxehf!c2_0+0x3f: >> 0040118f f7f3 div eax,ebx >> 0:000> g >> Breakpoint 1 hit >> eax=004011a7 ebx=0012fbb4 ecx=0012f90c edx=7c90eb94 esi=c0000005 >> edi=00000000 >> eip=004011a7 esp=0012f930 ebp=0012fb9c iopl=0 nv up ei pl nz na po >> nc >> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >> efl=00000202 >> suxehf!unhandled: >> 004011a7 55 push ebp >> >> >> >> >> On 1/12/09, chandra97 97 wrote: >>> >>> You can also use OllyDbg to debug your unhandled exception filter. But >>> you have to use OllyAdvanced Plugin with Ollydbg and check the Anti-Debug >>> option for SetUnhandledExceptionFilter. >>> >>> Do a google search on ollydbg & OllyAdvanced Plugin. >>> >>> Chandra >>> >>> On Sat, Jan 10, 2009 at 5:07 PM, raj_r wrote: >>> >>>> got some code like this running ? >>>> >>>> >>>> #include <stdio.h> >>>> #include <windows.h> >>>> >>>> LONG __stdcall unhandled( EXCEPTION_POINTERS excep ); >>>> >>>> int main (void) >>>> { >>>> >>>> DWORD a,b,c; >>>> SetUnhandledExceptionFilter(unhandled); >>>> printf (“relaunching this app after exception \n”); >>>> a= b = 2; >>>> c = a/b; >>>> printf(“first divide is %0x im going to divide by zero now for >>>> excepting\n”,c); >>>> a = 2; >>>> b = 0; >>>> c = a/b; >>>> printf (“this shouldnt be executing as result %0x is >>>> indeterminate\n”,c); >>>> return 1; >>>> } >>>> >>>> >>>> >>>> LONG__stdcall unhandled( EXCEPTION_POINTERS excep ) >>>> { >>>> >>>> printf (“shall i relaunch you %p\n”,excep); >>>> WinExec(“relaunched.exe”,SW_SHOWNORMAL); //obsolete do not use >>>> >>>> return EXCEPTION_EXECUTE_HANDLER; >>>> } >>>> >>>> >>>> >>>> relaunch>relaunched.exe >>>> relaunching this app after exception >>>> first divide is 1 im going to divide by zero now for excepting >>>> shall i relaunch you 0012FBB4 >>>> shall i relaunch you 0012FBB4 >>>> shall i relaunch you 0012F77C >>>> relaunching this app after exception >>>> first divide is 1 im going to divide by zero now for excepting >>>> shall i relaunch you 0012FBB4 >>>> shall i relaunch you 0012FBB4 >>>> shall i relaunch you 0012F77C >>>> relaunching this app after exception >>>> first divide is 1 im going to divide by zero now for excepting >>>> shall i relaunch you 0012FBB4 >>>> relaunching this app after exception >>>> first divide is 1 im going to divide by zero now for excepting >>>> shall i relaunch you 0012FBB4 >>>> shall i relaunch you 0012FBB4 >>>> relaunching this app after exception >>>> shall i relaunch you 0012FBB4 >>>> shall i relaunch you 0012F77C >>>> first divide is 1 im going to divide by zero now for excepting >>>> shall i relaunch you 0012FBB4 >>>> >>>> outside debugger it will keep on relaunching >>>> inside debugger it will keep on jumping to div ebx >>>> >>>> Log data >>>> Address Message >>>> 0040118F Integer division by zero >>>> 0040118F Integer division by zero >>>> 0040118F Integer division by zero >>>> 0040118F Integer division by zero >>>> 0040118F Integer division by zero >>>> 0040118F Integer division by zero >>>> 0040118F Integer division by zero >>>> 0040118F Integer division by zero >>>> >>>> >>>> >>>> 0040118F DIV EBX >>>> 00401191 PUSH EAX ; /<%0x> = 2 >>>> 00401192 PUSH relaunch.0040A191 ; |format = "this >>>> shouldnt be executing as result %0x is indeterminate >>>> " >>>> 00401197 CALL relaunch. ___org_printf ; ___ org_printf >>>> >>>> >>>> >>>> regards >>>> >>>> raj_r >>>> >>>> >>>> >>>> >>>> On 1/10/09, xxxxx@hotmail.com < >>>> xxxxx@hotmail.com> wrote: >>>> >>>>> Hello everyone >>>>> >>>>> First let me explain myself. >>>>> >>>>> I was programing a small program in C++ and I had a memory bug >>>>> (access violation) >>>>> >>>>> For some reason I had the Event Logger services disabled. you know the >>>>> annoying messagebox screaming at you “blabla.exe produced a error at >>>>> 0x00CC1122” >>>>> >>>>> and my program instead of crash quickly , Was re-launched for like 5 >>>>> times (new PID each time) >>>>> >>>>> But I wasn’t able to trace this behavior with windbg, at each time the >>>>> exception handler seem to know about my debugger and he is simply >>>>> continuing to jump at >>>>> the same location. >>>>> >>>>> But without windbg or any debugger the process is really ‘relaunched’ ! >>>>> >>>>> I tried to trace it with immunity dbg and a anti debug plugin. but I >>>>> failed to reproduce this (code relaunching) again >>>>> >>>>> so I wonder if any of you have any idea why windows want to continue to >>>>> relaunch my process and didn’t let him crash simply ? >>>>> >>>>> >>>>> thanks for your time! >>>>> >>>>> -Nico >>>>> >>>>> >>>>> — >>>>> You are currently subscribed to windbg as: unknown lmsubst tag >>>>> argument: ‘’ >>>>> >>>>> To unsubscribe send a blank email to xxxxx@lists.osr.com >>>>> >>>> >>>> — You are currently subscribed to windbg as: xxxxx@gmail.com To >>>> unsubscribe send a blank email to xxxxx@lists.osr.com >>> >>> >>> — You are currently subscribed to windbg as: unknown lmsubst tag >>> argument: ‘’ To unsubscribe send a blank email to >>> xxxxx@lists.osr.com >> >> >> — You are currently subscribed to windbg as: >> xxxxx@valhallalegends.com To unsubscribe send a blank email to >> xxxxx@lists.osr.com >> >> — >> You are currently subscribed to windbg as: unknown lmsubst tag argument: >> ‘’ >> To unsubscribe send a blank email to xxxxx@lists.osr.com >> > > — You are currently subscribed to windbg as: unknown lmsubst tag > argument: ‘’ To unsubscribe send a blank email to > xxxxx@lists.osr.com > > — > You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’ > > To unsubscribe send a blank email to xxxxx@lists.osr.com >
Yup, that would be about my usual recommendation. Not completely perfect in the multithreaded world, but usually what I use.
? S
From: raj_r Sent: Wednesday, January 14, 2009 11:21 To: Kernel Debugging Interest List Subject: Re: [windbg] about the default exception handler and how to trace it (acting curiously)
ken thanks
advice if the conditinal bp statement below comes closer to the mark
bp ntdll!ZwQueryInformationProcess “.if (poi(esp+8) == 7) { r $t1 = poi(esp+0xc);gu;? poi($t1);ed $t1 0;? poi($t1);bp suxehf!unhandled; } .else {gc}”
0:000> bp ntdll!ZwQueryInformationProcess “.if (poi(esp+8) == 7) { r $t1 = poi(esp+0xc);gu;? poi($t1);ed $t1 0;? poi($t1);bp suxehf!unhandled; } .else {gc}” 0:000> bl 0 e 7c90e01b 0001 (0001) 0:ntdll!NtQueryInformationProcess “.if (poi(esp+8) == 7) { r $t1 = poi(esp+0xc);gu;? poi($t1);ed $t1 0;? poi($t1);bp suxehf!unhandled; } .else {gc}” 0:000> g (b6c.b74): Integer divide-by-zero - code c0000094 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000002 ebx=00000000 ecx=00000002 edx=00000000 esi=0040a0b8 edi=00000000 eip=0040118f esp=0012ff88 ebp=0012ff8c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 WARNING: Unable to verify checksum for suxehf.exe suxehf!c2_0+0x3f: 0040118f f7f3 div eax,ebx 0:000> gn Evaluate expression: -1 = ffffffff Evaluate expression: 0 = 00000000 eax=00000000 ebx=0012fbb4 ecx=0012f91c edx=7c90eb94 esi=c0000005 edi=00000000 eip=7c862c17 esp=0012f938 ebp=0012fb9c iopl=0 nv up ei ng nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000286 kernel32!UnhandledExceptionFilter+0x8d: 7c862c17 85c0 test eax,eax 0:000> g Breakpoint 1 hit eax=004011a7 ebx=0012fbb4 ecx=0012f90c edx=7c90eb94 esi=c0000005 edi=00000000 eip=004011a7 esp=0012f930 ebp=0012fb9c iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 suxehf!unhandled: 004011a7 55 push ebp
On 1/14/09, Skywing > wrote: You are reaching into the callers stack frame with that bp. It is specific to the stack layout of UnhandledExceptionFilter on your build. Another build or another function calling NtQueryInformationProcess will result in a corrupted stack.
A more generic approach to that would be to indirect through the pointer passed to the api to write the zero value instead of groveling around directly in the callers stack frame and hoping it’s the right caller.
? S
From: raj_r > Sent: Tuesday, January 13, 2009 12:54
To: Kernel Debugging Interest List > Subject: Re: [windbg] about the default exception handler and how to trace it (acting curiously)
On 1/14/09, Skywing > wrote: Better to just write through the out param, or you’ll corrupt the stack should anyone else issue the call.
sorry i did not understand what do you mean by out param you mean i should have used some thing else instead of (ebp -124) (ebp-0x124) or poi(esp-0xc) seems to be the only two options after gu
if i have to get the address of unhandled exception filter then i would need to device some way to emulate rtldecodepointer giving it
7C8833AC kernel32.BasepCurrentTopLevelFilter DB 9E BE 45 ۞?E
value
thanks and regards
raj_r
? S
From: raj_r > Sent: Tuesday, January 13, 2009 11:21 To: Kernel Debugging Interest List > Subject: Re: [windbg] about the default exception handler and how to trace it (acting curiously)
you dont need any plugin or whatever just a conditional break in windbg can let you debug your unhandled exception filter even when you are debugging it i think ken already said so in one of the earlier post
ntdll!DbgBreakPoint: 7c901230 cc int 3 0:000> bp ntdll!ZwQueryInformationProcess “.if (poi(esp+8) == 7) {gu;ed (ebp-124) 0;bp suxehf!unhandled;g } .else {gc}”
all this line does is when debugport is queried on the said break it nulls out the return of -1
and you get to trace your unhandled exception filter stub
0:000> g (ee4.914): Integer divide-by-zero - code c0000094 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000002 ebx=00000000 ecx=00000002 edx=00000000 esi=0040a0b8 edi=00000000 eip=0040118f esp=0012ff88 ebp=0012ff8c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 ** WARNING: Unable to verify checksum for suxehf.exe suxehf!c2_0+0x3f: 0040118f f7f3 div eax,ebx 0:000> g Breakpoint 1 hit eax=004011a7 ebx=0012fbb4 ecx=0012f90c edx=7c90eb94 esi=c0000005 edi=00000000 eip=004011a7 esp=0012f930 ebp=0012fb9c iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 suxehf!unhandled: 004011a7 55 push ebp
On 1/12/09, chandra97 97 > wrote: You can also use OllyDbg to debug your unhandled exception filter. But you have to use OllyAdvanced Plugin with Ollydbg and check the Anti-Debug option for SetUnhandledExceptionFilter.
Do a google search on ollydbg & OllyAdvanced Plugin.
Chandra
On Sat, Jan 10, 2009 at 5:07 PM, raj_r > wrote: got some code like this running ?
#include <stdio.h> #include <windows.h>
LONG __stdcall unhandled( EXCEPTION_POINTERS* excep );
int main (void) {
DWORD a,b,c; SetUnhandledExceptionFilter(unhandled); printf (“relaunching this app after exception \n”); a= b = 2; c = a/b; printf(“first divide is %0x im going to divide by zero now for excepting\n”,c); a = 2; b = 0; c = a/b; printf (“this shouldnt be executing as result %0x is indeterminate\n”,c); return 1; }
printf (“shall i relaunch you %p\n”,excep); WinExec(“relaunched.exe”,SW_SHOWNORMAL); //obsolete do not use
return EXCEPTION_EXECUTE_HANDLER; }
relaunch>relaunched.exe relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 shall i relaunch you 0012FBB4 shall i relaunch you 0012F77C relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 shall i relaunch you 0012FBB4 shall i relaunch you 0012F77C relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 relaunching this app after exception first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4 shall i relaunch you 0012FBB4 relaunching this app after exception shall i relaunch you 0012FBB4 shall i relaunch you 0012F77C first divide is 1 im going to divide by zero now for excepting shall i relaunch you 0012FBB4
outside debugger it will keep on relaunching inside debugger it will keep on jumping to div ebx
Log data Address Message 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero 0040118F Integer division by zero
0040118F DIV EBX 00401191 PUSH EAX ; /<%0x> = 2 00401192 PUSH relaunch.0040A191 ; |format = “this shouldnt be executing as result %0x is indeterminate ” 00401197 CALL relaunch. ___org_printf ; ___ org_printf
I was programing a small program in C++ and I had a memory bug (access violation)
For some reason I had the Event Logger services disabled. you know the annoying messagebox screaming at you “blabla.exe produced a error at 0x00CC1122”
and my program instead of crash quickly , Was re-launched for like 5 times (new PID each time)
But I wasn’t able to trace this behavior with windbg, at each time the exception handler seem to know about my debugger and he is simply continuing to jump at the same location.
But without windbg or any debugger the process is really ‘relaunched’ !
I tried to trace it with immunity dbg and a anti debug plugin. but I failed to reproduce this (code relaunching) again
so I wonder if any of you have any idea why windows want to continue to relaunch my process and didn’t let him crash simply ?
thanks for your time!
-Nico
— You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
— You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.commailto:xxxxx
— You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.commailto:xxxxx
— You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.commailto:xxxxx
– thanks and regards
raj_r — You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></windows.h></stdio.h>