How do I suppress the error box that appears when a LoadLibrary fails?

Raymond Chen

If there is a problem loading a DLL via Load­Library or a related function, you sometimes get a system error box that says “Contoso.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support.” How can a program suppress this error message and just have Load­Library return NULL without fanfare?

The so-called “error mode” controls how things behave when various categories of bad things happen. One category of failure goes under the name SEM_FAIL­CRITICAL­ERRORS. This name sounds really vague, but at the time it was introduced, it wasn’t vague at all.

The term “critical errors” refers to MS-DOS interrupt 24h, known as the “critical error” interrupt. These errors were things like “No disk in drive” or “I/O error”, and your recovery options were the famous trio of Abort, Retry, and Ignore, later revised to Abort, Retry, and Fail. Saying that you want to “fail critical errors” obviously means that when these critical errors occur, you don’t want the system to prompt the user for action but rather act as if the user had selected “Fail”.

Windows expanded the category of things that were classified as “critical errors” to include “DLL not found”, so that the user could reinsert the floppy disk with the missing DLL. And in the intervening decades, various other miscellaneous file errors got tossed into the “critical errors” bucket. (Sound familiar?)

And that leads to the answer to the question.

To suppress error dialogs in functions like Load­Library, you can call Set­Error­Mode(SEM_FAIL­CRITICAL­ERRORS)¹

¹ More precisely, you want to add the SEM_FAIL­CRITICAL­ERRORS flag to whatever flags are already set.


Comments are closed. Login to edit/delete your existing comments

  • Piotr Siódmak 0

    Speaking of DOS errors, “This program cannot be run in DOS mode” is the best error, because it shows that the DOS legacy lives to this day.

    • Falcon 0

      Technically, that’s not an error as such, at least not an OS one.

      The legacy in this case is the existence of an MS-DOS “MZ” executable at the beginning of a PE image. Linkers normally insert a stub program that simply prints this message and exits, but it could be any MS-DOS program.

      I guess that makes PE a “fat binary” of sorts (supporting multiple OSes, rather than multiple architectures on one OS).

  • Melissa P 1

    Golden rule: Never suppress anything that you can’t do better.

    Silently crashing or ending the program, or dumping a message box “Internal error!” (notice the very important exclamation mark) is not helpful. Then you start the annoying cycle of “we need more information” and “we cannot reproduce”, until you realize suppressing that message box wasn’t the wisest decision.

    On the other hand, a well written text about which library is missing, why it’s needed and where to find it can make any customer happy.

Feedback usabilla icon