I took a look at my edition of Windows Internals, but it doesn't have a whole lot to say on the subject. In earlier versions, the windows error reporting routine took place in the context of the crashing thread. This means that if the stack is trashed (as in your example), it might not be able to run.
In Vista and later, it runs externally to the crashing thread. In addition, the kernel itself is responsible for notifying WER when a process crashes (through an advanced local procedure call).
According to Windows Internals, these changes fix the vanishing process problem. I can only take their word for that. Obviously, if the WER service is itself damaged (or stopped), you'll still get silent crashes.
EDIT
From Windows Internals, 5th Edition, page 122:
Until Windows Vista, all the [WER] operations we've described had to occur within the crashing thread's context... In certain types of crashes ... the unhandled exception filter itself crashed. This "silent process death" was not logged anywhere. ... Windows Vista and later versions improved the WER mechanism by performing this work externally from the crashed thread, if the unhandled exception filter itself crashes.
Page 124:
...all Windows processes now have an error port that is actually an ALPC port object registered by the WER service. The kernel ... will use this port to send a message to the WER service, which will then analyze the crashing process. ... This solves all the problems of silent process death...