Fix T69935: Silence OS Error Dialogs
ClosedPublic
Actions

Authored by Harley Acheson (harley) on Sep 29 2019, 7:21 PM.

Details

Reviewers

Brecht Van Lommel (brecht)
Ray Molenkamp (LazyDodo)

Commits

rB3a3e5fb365ba: Fix T69935: Silence Win32 OS Error Dialogs

Summary

Adds SetErrorMode() to GHOST_SystemWin32::init() so it will quiet OS-supplied error dialogs process-wide.

Appears to be best practice to do this once in startup, see this windows api doc.

Uses all four uMode flag values:

SEM_FAILCRITICALERRORS - no critical-error-handler message box
SEM_NOGPFAULTERRORBOX - no Windows Error Reporting dialog
SEM_NOOPENFILEERRORBOX - no OpenFile dialog if OS cannot find a file
SEM_NOALIGNMENTFAULTEXCEPT - FIX memory alignment faults

Since this sets this process-wide in startup, this patch removes the (transitory) usage of of SetErrorMode in BLI_exists() since leaving it would be redundant and possibly confusing later.

Diff Detail

Repository: rB Blender

Event Timeline

Harley Acheson (harley) created this revision.Sep 29 2019, 7:21 PM

We should probably do this outside of GHOST, so that it also works when running Blender in background mode.

I think main_signal_setup in creator_signals.c is a good place, since that's where we also setup the functions to catch these kinds of errors.

@Brecht Van Lommel (brecht) - We should probably do this outside of GHOST, so that it also works when running
Blender in background mode. I think main_signal_setup in creator_signals.c is a good place,
since that's where we also setup the functions to catch these kinds of errors.

Yes, placed there it does get called just the once early on as expected. So I updated the patch to move it there. However, I am not at all familiar with that area of code and have no idea if app_state.signal.use_crash_handler is ever false for example.

So compiles, gets called as expected. But hard to truly confirm this change on my system, only because I have no devices that I can force to show the same error as the original complainant. For example, without this patch (so no call to SetErrorMode), compiling release and running from command prompt, I get no OS error dialog if I force an error somewhere - like with *((unsigned int *)0) = 0xDEAD; - Blender just crashes without notice. So I am, in effect, silencing dialogs that I am not seeing.

Just move it outside of if (app_state.signal.use_crash_handler) and add another # ifdef WIN32 around it.

@Brecht Van Lommel (brecht) - Just move it outside of if (app_state.signal.use_crash_handler)...

Yes, did so. And confirmed again that it is called just fine when expected. Sorry for the dumb back-and-forth on this, but just cautious about making changes in areas that I am unfamiliar with. Thanks, as always, for your help.

Brecht Van Lommel (brecht) accepted this revision.Sep 29 2019, 8:31 PM

This revision is now accepted and ready to land.Sep 29 2019, 8:31 PM

Closed by commit rB3a3e5fb365ba: Fix T69935: Silence Win32 OS Error Dialogs (authored by Harley Acheson (harley)). · Explain WhySep 29 2019, 8:43 PM

This revision was automatically updated to reflect the committed changes.

Harley Acheson (harley) added a commit: rB3a3e5fb365ba: Fix T69935: Silence Win32 OS Error Dialogs.