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

[David Allsopp]

On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
>
> 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.

:o) Never knowingly clear, are they! It would seem to be the intent of
SetThreadErrorMode that it would behave that way but who knows.

Happy to set up a quick experiment to check that it does work (i.e.
the invoked process has GetErrorMode set as expected) and that there's
no possible race between two threads in the calling process with
differing values (i.e. that having SEM_FAILCRITICALERRORS in one
thread and not in another behaves as expected. If it does appear to
work consistently, would you be willing to go down this route? Happy
to do the patch, although it'd be very helpful to have a couple of
pointers: I'm guessing the value would want to be captured just before
the one place where SetErrorMode is already called, but in which
structure should it then be stashed away to be reused in spawn?


David