Re: confused by exception handling in VC 2008
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:tbf9k4tlpv1uagc7cvgc2vdtf7pag2l0ot@4ax.com...
3)
__try {
char *p = 0;
int v[5];
v[10] = 1; // This vector access is out of range
*p = '\0';
AfxMessageBox("no exception");
}
__except (EXCEPTION_EXECUTE_HANDLER){
AfxMessageBox("exception caught");
}
I suspect that your bad assignment clobbered the exception frame and
therefore the
exception handler could not execute. This then manifested itself as some
other error that
you gave no details about.
Just a note: The assignment could never have touched the exception frame's
first entry as that is not located on the stack, or even accessible via
"[reg/val]".
The SEH exception chain's head is stored far far away in (probably)
USER32.DLL's data area. Like right now I'm looking at it and it's sitting
there at 0x7FFDF000 and USER32.DLL's base address happens to be 0x7E410000
with nothing above it. The stack is around 0x0012FF3C or so. Of course he
certainly could've trashed the 2nd entry which actually *is* on the stack,
if that's what you meant... but that's really unlikely since there's already
a bunch of ret's on the stack, argc and argv (min 12 bytes so far) plus his
5 ints (another 20 bytes). In fact, typically the value for the location of
the next exception handler with respect to esp on entry to main is about
"esp+150" (with no variables declared), and that's the closest you'll ever
get to it! He only went 20 bytes into "uncharted territory" and probably
knocked out a return address I'm guessing. Maybe the OS, or CRT does a
little stack walk before jumping to the first __except block... That's my
guess.
=========================
BTW. In case you don't know all this already, there's a VERY easy way to
access the SEH chain along with a whole lot of other interesting USER32 data
which is this:
Amazing Fact 1: Windows sets the "FS" segment's base address to point
exactly at the head of the SEH chain!
So here's how you'd jump to the first entry:
__asm mov eax, fs:[0h]
__asm mov eax,[eax]
__asm jmp dword ptr[eax+4h]
That's the address the first exception handler in the chain (it's just a
simple linked list). There's a bunch of other interesting structures offset
from fs:[0h], for instance the PEB and TEB structures ("officially"
undocumented of course) defined in winternl.h. The magic offset fs:[18h] is
where all the action starts:
Amazing Fact 2:
__asm mov eax,fs:[00000018]
__asm mov eax,[eax+0x30]
Gets you the PEB (process environment block I guess).
struct PEB {
BYTE Reserved1[2];
BYTE BeingDebugged;
BYTE Reserved2[229];
PVOID Reserved3[59];
ULONG SessionId;
};
So, you know...
BOOL IsDebuggerPresent() {
__asm {
mov eax,dword ptr fs:[18h]
mov eax,dword ptr [eax+30h]
movzx eax,byte ptr [eax+2]
}
}
etc... (here's another struct you can find through fs:
struct TEB {
BYTE Reserved1[1952];
PVOID Reserved2[412];
PVOID TlsSlots[64];
BYTE Reserved3[8];
PVOID Reserved4[26];
PVOID ReservedForOle; // Windows 2000 only
PVOID Reserved5[4];
PVOID TlsExpansionSlots;
};
Thread environment block I guess.
==================
Anyway... just something of interest. These values change version to version
of course, !BUT! the one thing that NEVER EVER changes is fs:[0h]. You never
need to 'know' the address of the SEH chain. It's always right there at 0.
- Alan Carre