Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

Corinna Vinschen
Fri Feb 2 14:16:44 GMT 2024

On Feb  2 13:35, David Allsopp via Cygwin wrote:
> Jon Turney via Cygwin wrote:
> > > I'm sympathetic, and personally I would prefer to revert the patch and
> > > stick to SEM_FAILCRITICALERRORS by default.
> > >
> > > The question is this: Why does, apparently, everybody expect Cygwin to
> > > do the "right thing", with different definitions of "right", when in
> > > fact the executable in question can easily call SetErrorMode by itself?
> >
> > Yeah, if cygwin wasn't involved in the process ancestry, how would you
> > get the behaviour you want?
> Ah, but that's how I hit this (and started digging further) -
> precisely because the non-Cygwin program I'm using _has_ called
> SetErrorMode and its direct calls to the faulty program _are_ doing
> what's wanted (no popup dialog) but the calls which happen via Cygwin
> are then torching that preference.
> Not really suggesting it be done this way (it feels more complicated
> than just reverting the change), but in some ways perhaps Cygwin
> should be using GetErrorMode on startup and instead of not inheriting
> it, ensuring that it sets whatever it received? i.e. just before the
> call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> error mode (for that thread only) to the value read at startup, calls
> CreateProcess and then sets the error mode back.

This sounds like a good ide, but...

Is it actually a safe bet that the error mode set by SetThreadErrorMode
is then propagated as process error mode to the child process?

I have to ask that because Microsoft conveniently forgot to document
this scenario in the MSDN docs.


More information about the Cygwin mailing list