The exit codes for the regsvr32 program are
currently as follows:
| Exit code |
Meaning |
| 0 |
Success |
| 1 |
Error parsing command line |
| 2 |
OleInitialize failed |
| 3 |
LoadLibrary failed |
| 4 |
GetProcAddress failed |
| 5 |
Registration function failed |
This information is included for diagnostic and troubleshooting
purposes.
I don't think the values are contractual.
The regsvr32 program basically does five things,
and the exit codes correspond to each of those steps.
- Parse the command line to see what it's being
asked to do.
- Initialize OLE.
- Load the library.
- Find the function to be called. The command line options
specify which function to look for.
Could be
DllRegisterServer,
DllUnregisterServer,
or even
DllInstall.
- Call it.
Steps 4 and 5 may be repeated if the command line options
indicate that multiple functions should be called.
If something goes wrong, the regsvr32 program
reports the error details to the user,
and the exit code summarizes which step it got stuck at.
Future versions of regsvr32 may add additional steps,
or change the order of the steps,
which would trigger renumbering.
The exit code is for diagnostic and troubleshooting purposes,
so you can try to figure out why something went wrong.
We'll put this information to use next time.
I always believed the 5 was an ERROR_ACCESS_DENIED getting passed through. Interesting.
Why not update the official documentation to include the exit codes and make them contractual?
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/regsvr32#BKMK_examples
Then it would be impossible to add new exit codes.
No, you would just have to document the new ones.
That would be a breaking change. “We wrote a program that checks the return value and assumes that code 3 means that LoadLibrary failed. But you introduced a new return value 6 that means “LoadLibrary failed because the DLL is not signed.” This is a bug. That situation should be reported as code 3, because that’s how you documented it. You can’t make breaking changes like this. Our product relies on the error codes as they were documented.”
Maybe future versions could elevate if necessary, to save me having to remember I need an elevated command prompt.
But then you wouldn’t be able to run it silently. It would display an elevation prompt and hang your batch file.
I thought it would just return the error code of the corresponding API like this:
https://support.microsoft.com/en-us/help/932628/fix-error-message-when-you-use-the-regsvr32-exe-command-line-utility-t
If the DLL being registered returns an error, that error code is reported on the screen, but regsvr32 exits with code 5 (“DLL explicitly failed registration”).
Doesn’t regsvr32.exe (step 3a) launch its sister version of another bitness if the 32 bit version of regsvr32.exe is asked to register a 64 bit dll (and vice versa)?
Those return codes were hinted at the now deleted KB207132 (formerly Q207132) article from Microsoft Support, titled “INFO: How Regsvr32.exe Registers and Unregisters COM DLLs”. An archived copy can be recovered from the Wayback Machine, but the sample code appears garbled because the line returns are missing. An even older copy can be located elsewhere and a more elaborated code sample is found in the Visual C++ Samples repository. However, that doesn’t mean any connection to the official Regsvr tool, obviously!
https://web.archive.org/web/20161219202259/support.microsoft.com/en-us/kb/207132
https://github.com/Microsoft/VCSamples/blob/master/VC2010Samples/MFC/controls/regsvr/regsvr.cpp