none
Vbscript Exit Code

    Question

  • Hello,

    i'm using a software that is automatically running Vbscripts and prints out the output. i want the software

    to print out the same message each time the script fails to run, due to a VBScript runtime error. the software runs the script as a command, like this:

    cscript c:\script.vbs Hostname.

     does anyone know what Exit Code does vbscript use when it fails to run? i don't need to know the exact value, just different from X.

    up until now i i used a comparison to 0. if the exit code is different then 0 i printed out the failed message, but it looks like vbscript returns 0 as exit code even if it fails to run. is that possible and does anyone have a solution?

    Thanks.

    Monday, August 23, 2010 11:51 AM

Answers

  • (1) Assuming that your test.vbs files don't write to StdErr, your 'software' could check for non-empty .StdOut.ReadAll()

    (2) Assuming your test.vbs don't contain a "WScript.Quit n" line: Add such a line to the end of your top level code - e.g.

              '' newbad.vbs - bad test
              WScript.Echo "divide by zero"
              WScript.Echo 1 / 0
              WScript.Quit 1 ' won't be reached

         vs.

              '' newgood.vbs - good test
              WScript.Echo "good"
              WScript.Quit 1 ' will be reached

         and invert the check in your 'software' (ERRORLEVEL 1 means tail reached ok)

    Tuesday, August 24, 2010 9:50 PM

All replies

  • What exactly do you mean with "fails to run"? When it terminates because of some script error?

    Anyway, you can easily answer the question yourself. Create some test script that contains the type of error you wish to monitor, then do this:

    1. Click Start, then type the three letters cmd into the Search box and press Enter.
    2. Type these commands and press Enter after each:
        NameOfScript.vbs
        echo %ErrorLevel%

        or perhaps
        cscript //nologo NameOfScript.vbs
        echo %ErrorLevel%

    Monday, August 23, 2010 12:35 PM
  • Pegusus, this is a bit trickier than I thought at first.  I just checked and found that syntax and runtime errors return zero exit codes at a command prompt.  That surprises me.  I would have thought they would return an errorlevel of one or more.  So, I think the ultimate solution may require more than one piece. 

    Momer,

    For starters, though it's not something I often suggest, but you could add an "On Error Resume Next" statement at the head of the script and then add a statement like this ...

      if err.number <> 0 then wsh.quit err.number

    at likely points of error in the script.  It returns the error number as an exit code.

    If you do this, I would recommend you also try to manage the likely errors, but that's more complicated.  At least, the placement of the Quit statements will give indications of the 'real' problems, based on the returned error number.

    If you also have control of how the script gets called, you could try modifying the command to be something like this to try to react to syntax errors ...

      %comspec% /c cscript //nologo c:\script.vbs Hostname | find /v /i "error" > nul

    Though I assume the Hostname part is a replaceable argument, which complicates this approach.  It just might not be possible in your case.  I'd need to know a lot more about the way the script gets invoked to say any more about this approach.


    Tom Lavedas
    • Proposed as answer by Code Chief Tuesday, July 30, 2013 12:02 PM
    Monday, August 23, 2010 1:02 PM
    Moderator
  • Syntax errors cause an ERRORLEVEL of 1:

    type syntaxerror.vbs
    '' syntaxerror.vbs - force a syntax error
    +

    cscript syntaxerror.vbs
    M:\trials\23forum\syntaxerror.vbs(2, 1) Microsoft VBScript compilation error: Expected statement

    echo %ERRORLEVEL%
    1

    (VBScript 5.7.16599 * cscript 5.7 * WIN XP)

     

    Monday, August 23, 2010 2:32 PM
  • Strange, on my XP SP3 machine I get this result for this error ...

    C:\>type test.vbs
    set test="string"

    C:\>cscript test.vbs
    C:\test.vbs(1, 1) Microsoft VBScript runtime error: Object required: '[string: "string"]'

    C:\>echo %errorlevel%
    0

    C:\>

    I get the same result as you for the script you used and for an unterminated string error.  But the 'Object required' error returns zero.  That means some compilation errors return no-zero errorlevels and some do!
    Tom Lavedas
    Monday, August 23, 2010 8:37 PM
    Moderator
  • syntax error <> runtime error
    Tuesday, August 24, 2010 7:19 AM
  • syntax error <> runtime error

     

    Tuesday, August 24, 2010 7:21 AM
  • Oh, I failed to read all of the words.  So, all runtime errors are left to be handled by the script.  I guess that makes sense.

    Tom Lavedas
    Tuesday, August 24, 2010 11:54 AM
    Moderator
  • well, thanks guys. that's what i thought.

    its totally stupid and it totally sucks. i was sure that vbscript returns 1 or something  for a runtime error, that is the

    way all the scripts are written.

    the software just runs the command at the comman line of the operating system automatically, is its windows or

    linux, whatever. it gets the return code and if it is different then 0 it prints out that there is an error in running the test.

    this means for me, that if no one has a different solution then "on Error Resume Next" , i will have to go through tens of scripts and modify them in a very ugly and inefficient way.

    can you think of anything else, some kind of simple modification in the script itself that will make vbscript output something else then 0 or some other solution?

    i know i'm optimistic :)

     

    Tuesday, August 24, 2010 6:33 PM
  • (1) Assuming that your test.vbs files don't write to StdErr, your 'software' could check for non-empty .StdOut.ReadAll()

    (2) Assuming your test.vbs don't contain a "WScript.Quit n" line: Add such a line to the end of your top level code - e.g.

              '' newbad.vbs - bad test
              WScript.Echo "divide by zero"
              WScript.Echo 1 / 0
              WScript.Quit 1 ' won't be reached

         vs.

              '' newgood.vbs - good test
              WScript.Echo "good"
              WScript.Quit 1 ' will be reached

         and invert the check in your 'software' (ERRORLEVEL 1 means tail reached ok)

    Tuesday, August 24, 2010 9:50 PM
  • Pegusus, this is a bit trickier than I thought at first.  I just checked and found that syntax and runtime errors return zero exit codes at a command prompt.  That surprises me.  I would have thought they would return an errorlevel of one or more.  So, I think the ultimate solution may require more than one piece. 

    Momer,

    For starters, though it's not something I often suggest, but you could add an "On Error Resume Next" statement at the head of the script and then add a statement like this ...

      if err.number <> 0 then wsh.quit err.number

    at likely points of error in the script.  It returns the error number as an exit code.

    If you do this, I would recommend you also try to manage the likely errors, but that's more complicated.  At least, the placement of the Quit statements will give indications of the 'real' problems, based on the returned error number.

    If you also have control of how the script gets called, you could try modifying the command to be something like this to try to react to syntax errors ...

      %comspec% /c cscript //nologo c:\script.vbs Hostname | find /v /i "error" > nul

    Though I assume the Hostname part is a replaceable argument, which complicates this approach.  It just might not be possible in your case.  I'd need to know a lot more about the way the script gets invoked to say any more about this approach.


    Tom Lavedas

    This is the best answer for many reasons:
    1.You don't have to change the script. It's the hosts' (CSCRIPT) fault not your script and that is where it should be dealt with.
    2.Some "syntax" errors are treated as runtime errors, e.g. when "Option Explicit" is on and you try to use an undefined variable/have a typo.
    3.Because of #2 it is very dangerous to use "On Error Resume Next" because it is impossible and crazy to have to check after every part of every statement whether the Err.Number has been set. And this number is reset at the next successful statement so it's just useless. Imagine a script doing something important like creating users or configuring a database, it could go off and damage your environment or corrupt data. Definitely not a sound solution. MS should have added On Error Do <something>, i.e. "WScript.Quit Err.Number" being the most sensible default.

    Here's an extended version of Tom's solution with a bit more accuracy, which also supports log files (remove " >> c:\logfile.txt 2>>&1" if you don't want that):

    %comspec% /c cscript //nologo c:\script.vbs parameters >> c:\logfile.txt 2>>&1
     set myreturncode=%ERRORLEVEL%
     if %myreturncode% == 0 (
        rem Also check for VBScript runtime errors which CSCRIPT does not return
        for /f "delims=" %%x in ('findstr /C:"Microsoft VBScript runtime error:" "c:\logfile.txt"') do @set myreturncode=1
     )
     if %myreturncode% neq 0 exit /b %myreturncode%

    Does the job for me. This issue seems to have been known for a long time so I guess MS don't want to change that behaviour. I guess the long term solution is to migrate to PowerShell. What an oversight that was. Who thought it was okay to return zero for runtime errors when On Error Resume Next was NOT set?!?!?!!!


    Key Artefacts

    Tuesday, July 30, 2013 1:24 PM
  • Hi,

    This question was marked as answered back in 2010, nearly 3 years ago. If you still need help, please start a new question.

    Bill

    Tuesday, July 30, 2013 1:40 PM
    Moderator
  • Just fixing the answer, it doesn't work for me as originally posted and this covers more requirements.

    This is almost at the top of search results when investigating the problem. It may help somebody else.

    I don't think posting another "question" which is already an answer is the correct thing to do either?

    Well thanks for not deleting it anyway.


    Key Artefacts

    Tuesday, July 30, 2013 2:14 PM
  • It is a corner case, but this script will give you a false positive:

     WScript.Echo "I would never code a script that yields a Microsoft VBScript runtime error: string"

    Since we are looking for an error string, I see no reason to redirect both stdout and stderr to the same file.

    Third, _appending_ to the file will give you a false positive if you run a correct script after an incorrect one.

    So just the first line needs to change to:

    %comspec% /c cscript //nologo c:\script.vbs parameters 2>c:\logfile.txt

    Tuesday, July 29, 2014 4:37 PM