Almost all applications and utilities will set an Exit Code when they complete/terminate.
The exit codes that are set do vary, in general a code of 0 (false) will indicate successful completion.
The exit codes set by resource kit utilities are not always consistent, they can vary between machines with different Service packs/Resource kit updates applied. Some utilities will return negative numbers as an exit code.
If you attempt to execute a non-existent command %ERRORLEVEL% = 9009
There are two different methods of checking an errorlevel, the first syntax provides compatibility with ancient batch files from the days of Windows 95
The exit code is made available via IF ERRORLEVEL ... or the %ERRORLEVEL% variable.
IF ERRORLEVEL n statements should be read as IF Errorlevel >= number
IF ERRORLEVEL 0 will return TRUE whether the errorlevel is 0, 1 or 5 or 64
IF ERRORLEVEL 1 will return TRUE whether the errorlevel is 1 or 5 or 64
IF NOT ERRORLEVEL 1 means if ERRORLEVEL is less than 1 (Zero or negative).
This is not very readable or user friendly and does not account for negative error numbers.
A better (more logical) method of checking Errorlevels is to use the %ERRORLEVEL% variable:
IF %ERRORLEVEL% NEQ 0 Echo An error was found
IF %ERRORLEVEL% EQU 0 Echo No error found
IF %ERRORLEVEL% EQU 0 (Echo No error found) ELSE (Echo An error was found)
IF %ERRORLEVEL% EQU 0 Echo No error found || Echo An error was found
This allows you to trap errors that can be negative numbers, you can also test for specific errors:
IF %ERRORLEVEL% EQU 64 ...
When ending a subroutine, you can use EXIT /b N to set a specific ERRORLEVEL N.
You should never attempt to write to the %ERRORLEVEL% variable because the value you set will create a user variable named ERRORLEVEL which then takes precedence over the internal pseudo variable ERRORLEVEL.
When an external command is run by CMD.EXE, it will detect the executable's return code and set the ERRORLEVEL to match. In most cases the ERRORLEVEL will be the same as the exit code, but there are a few buggy cases where this fails.
The Exit Codes can be detected directly with redirection operators (Success/Failure ignoring the ERRORLEVEL)
Commands that do NOT affect the ERRORLEVEL:
BREAK, ECHO, ENDLOCAL, FOR, IF, PAUSE, REM, RD/RMDIR, SET, TITLE
Commands that will set but not clear an ERRORLEVEL:
CLS, GOTO, KEYS, POPD, SHIFT
Commands that set an Exit Code but not the ERRORLEVEL:
Commands that set an ERRORLEVEL but not the Exit Code (SO explanation):
You can make a batch file return a non-zero exit code by using the EXIT command.
Exit /B 5
To force an ERRORLEVEL of 1 to be set without exiting, run a small but invalid command like COLOR 00
There is a key difference between the way .CMD and .BAT batch files set errorlevels:
An old .BAT batch script running the 'new' internal commands: APPEND, ASSOC, PATH, PROMPT, FTYPE and SET will only set ERRORLEVEL if an error occurs. So if you have two commands in the batch script and the first fails, the ERRORLEVEL will remain set even after the second command succeeds.
This can make debugging a problem BAT script more difficult, a CMD batch script is more consistent and will set ERRORLEVEL after every command that you run [source].
In PowerShell $? contains True if last operation succeeded and False otherwise.
The exit code of the last Win32 executable execution is stored in the automatic variable $LASTEXITCODE
To read exit codes (other than 0 or 1) launch the PowerShell script and return the $LASTEXITCODE in a single line like this:
powershell.exe -noprofile C:\scripts\script.ps1; exit $LASTEXITCODE
“I’d rather wake up in the middle of nowhere than in any city on earth” ~ Steve McQueen
Robocopy exit codes
Conditional Execution - if command1 succeeds then execute command2
ERRORLEVEL is not %ERRORLEVEL% - The old new thing blog