It my unhandled exception filter did work. I took a convoluted path for replacing SetUnhandledExceptionFilter to ensure mine would execute first (allowing me to bypass mingw's). I also noticed that my attempt to install a fake exception frame handler also failed. It might've had something to do with
[...]
I don't know if gcc emits safe handlers or not, but C4733 could also be the reason why yours didn't work. Apparently executables can contain a list of valid SEH addresses, and if it's not on that list, then it won't accept it.
Wow. First I've heard of that. I knew x64 had something like that, but not x86. Neat. But troublesome. I'll have to remember that.
I'm pretty sure, though, that GCC 3.4.x doesn't support it. It's too old. And, frankly, development of GCC tends to lag; it's never cutting-edge.
> ntdll.dll!@RtlpCreateSplitBlock@28() + 0x51 bytes
ntdll.dll!@RtlpAllocateHeap@20() + 0x348 bytes
ntdll.dll!_RtlAllocateHeap@12() + 0x2eac bytes
msvcrt.dll!_malloc() + 0x57 bytes
Malloc! Why would malloc throw? Okay, There are two mallocs in main().
myname = malloc(strlen(argv[0] + 2));
[...]
myininame = malloc(MAX_PATH+8);
And those are the only two stdlib.h *allocs in the program.
Okay, hmmm. Those look reasonable to me. But at least one of them doesn't work. Fine. They both can be replaced with fixed-size MAX_PATH based buffers.
That maybe explains why the code works when run in the debugger. Under Unix/Linux, malloc behaves differently under a debugger, in that it fills the requested area with a 0xDEADBEEF-type pattern, and a few bytes beyond the area with a different pattern. Maybe MSVCRT does the same thing, checking IsDebuggerPresent.
Okay, I just sent you a couple builds without malloc calls, and a third that deliberately crashes itself.