What is a hard error, and what makes it harder than an easy error?
Occasionally, you may see a reference in Windows to “hard errors”, such as in this article that shows how to configure an unattended system so that it auto-answers hard error dialogs. But why is it called a “hard error”? Are there “easy errors”?
In 16-bit Windows, if there was an I/O error reading a drive, you got an error message that looked like this:
| System Error |
| Cannot read from drive B. |
|
Abort
Retry
Cancel
|
These messages were special because they were generated from inside the I/O system, below the user interface level. Windows can’t put up a traditional MessageBox because that pumps messages and allows application code to run at a time when the rules of co-operative multitasking say that application code should not be running.
The code to display these special “hard system modal errors” was carefully written so as to rely only on parts of the user interface code that were re-entrant. In fact, the only user interface code it uses is processing mouse and keyboard input. All of the graphics are drawn by asking GDI to draw directly to the frame buffer, and all of the dialog behaviors are handwritten. No application code was allowed to run while this message was being shown to the user.
The opposite of the “hard error” message was the “soft error” message, which was your regular MessageBox.
These types of hard error messages disappeared from 32-bit Windows, but the name got repurposed to describe other types of critical error messages, usually low-level ones.
Light
Dark
4 comments
Long, long ago, when Windows 3.1 ruled the world and source control wasn’t something most people had even heard of, I worked for a company that no longer exists writing software that no longer exists, and we kept all of our source code on a shared network drive. Whenever we would run a build, we’d invariably run into a sharing violation because someone else was also doing a build and was accessing a file we needed. This was annoying, because it meant you couldn’t start a build and go get a cup of coffee, because it’d just be sitting on an error dialog when you returned.
If my memory is accurate, the sharing violation dialog was one of those hard error boxes.
The first solution we found for this was to bend a paperclip into a sort of hook shape that you could place on top of the R key, press down, and hook under the 5 key. This would hold down the R key for you, automatically retrying any sharing violations while you enjoyed your coffee. It also helped to unplug your PC speaker, for the sake of your teammates.
For some reason, probably that PC speaker thing, we didn’t think that solution was sufficiently elegant. So, one day while I was bored, and probably with the help of Schulman, Maxey, and Pietrek’s “Undocumented Windows,” I sat down and wrote a little program whose sole purpose in life was to detour whichever function brought up those message boxes. (This worked because Windows 3.1 didn’t have separate process memory – every process used the same copies of every DLL.) The detour would look to see if the message started with the word “Sharing,” and if it did, it would automatically return the “Retry” result 49 times out of 50. (Thus giving you an opportunity to cancel if it really was unrecoverable.)
So, at least in the case of a tiny handful of developers in a tiny rural town in northeast Indiana, there was a little bit of application code running during a hard error state.
(And y’all can put down your torches and pitchforks. We did eventually spring for a license for that newfangled “SourceSafe” thing, unfortunately before Microsoft bought out One Tree Software and, again IIRC, made it available through our existing MSDN subscription.)
There’s a nonsense poem in the Unix fortune file that refers to “hard errors”. In that context, it probably means “hard[ware] errors”, and that’s the interpretation I’d have placed on the phrase before reading this article.
It is also consistent with the Windows usage meaning “low-level critical error”.