The default error mode (SetErrorMode) is not zero

Raymond Chen

Raymond


A customer put the following code at the start of their program:



// If this assertion fires, then somebody else changed the error mode
// and I just overwrote it with my error mode.
ASSERT(SetErrorMode(SEM_FAILCRITICALERRORS) == 0);


The customer wanted to know whether it was a valid assumption
that the initial error mode for a process is zero.



No it is not, and this is called out in the documentation for

Set­Error­Mode
:




Remarks



Each process has an associated error mode that indicates
to the system how the application is going to respond to serious errors.

A child process inherits the error mode of its parent process.




The assumption that the initial error mode is zero is therefore false.



There’s another error in the above code:
The call to
Set­Error­Mode is placed inside an assertion.
This means that in the retail build, the call disappears.
The debug build has the error mode set to
SEM_FAIL­CRITICAL­ERRORS,
but the retail build has the default error mode.
They are

changing the semantics in the debug build
,
and are headed down the slippery slope that leads to them being forced
to deploy the debug version of the program into production
because that’s the only build that works.



Unfortunately, they may have already reached that point,
because the customer asked,
“Is it possible for the user to set the default error
code to something other than zero,
in which case this assertion would crash the client?”
(Emphasis mine.)



Bonus chatter:
Note that you can override error mode inheritance
by passing the
CREATE_DEFAULT_ERROR_MODE
flag to the Create­Process function.

Raymond Chen
Raymond Chen

Follow Raymond