locked
Errorlevels not being reset RRS feed

  • Question

  • Ok, so I'm quite embarrassed to post this but I'm completely stumped.  I've tried it across various computers and the same result.  When I use a batch file or go direct to the command prompt and enter the commands below it does not properly report errorlevels.  These are the commands :

    msiexec /x {123456} /qb

    echo %errorlevel% >>"%TEMP%\log.txt"

    Again, whether a batch or a cmd prompt it spits out errorlevel of "0", not 1619 or 1605.  Try it out, and yes its an invalid GUID.  Now another example is if I run a command prompt and enter a bad command to get a 9009 error and then run msiexec /x it still holds the 9009, it never resets the errorlevel to what it should be.  See photo below:

    Now if I run an msiexec /x with an incorrect GUID from vbscript and echo out an error code to a log it reports accurately.  What am I missing as I'm sure its something simple and I feel dumb for asking this.  The end goal is for it to properly report an error level so if it fails an uninstall it will tell me the error code in the log and report it back up to SCCM for a proper response from technicians.  Thanks for any input.  


    Be kind and Mark as Answer if I helped.

    Tuesday, March 25, 2014 7:46 PM

Answers

  • msiexec will run asynchronously unless you specify otherwise.


    C:\>start /wait msiexec /x {123456} /qb
    
    C:\>echo %ERRORLEVEL%
    1619
    

    start /wait will run msiexec synchronously so you can get its exit code.


    -- Bill Stewart [Bill_Stewart]

    • Proposed as answer by Mike Laughlin Tuesday, March 25, 2014 8:33 PM
    • Marked as answer by Chris DeCarlo Wednesday, March 26, 2014 2:08 PM
    Tuesday, March 25, 2014 8:16 PM

All replies

  • msiexec will run asynchronously unless you specify otherwise.


    C:\>start /wait msiexec /x {123456} /qb
    
    C:\>echo %ERRORLEVEL%
    1619
    

    start /wait will run msiexec synchronously so you can get its exit code.


    -- Bill Stewart [Bill_Stewart]

    • Proposed as answer by Mike Laughlin Tuesday, March 25, 2014 8:33 PM
    • Marked as answer by Chris DeCarlo Wednesday, March 26, 2014 2:08 PM
    Tuesday, March 25, 2014 8:16 PM
  • Unfortunately MSIEXEC usually uses a bootstrap that executes a second copy of MSI.  The second copy runs async to the first. More copies can be released if the product has many parts.  You can only successfully wait on MSI with very simple install databases.  If it doesn'5t work there is not much you can do.


    ¯\_(ツ)_/¯

    Tuesday, March 25, 2014 9:56 PM
  • True; it depends on what gets called. Using start /wait only waits for the executable you specifically start; if the one you start starts something else, then start /wait doesn't know about it and doesn't wait for it.


    -- Bill Stewart [Bill_Stewart]

    Tuesday, March 25, 2014 10:09 PM
  • Thanks Bill and JRV, that helps.  I've used start /wait before but never really ran into an issue with not using it.  Batch is just a very peculiar language, vbscript handles error handling much better......and probably powershell as well.  Thanks again.

    Be kind and Mark as Answer if I helped.

    Wednesday, March 26, 2014 2:10 PM
  • Thanks Bill and JRV, that helps.  I've used start /wait before but never really ran into an issue with not using it.  Batch is just a very peculiar language, vbscript handles error handling much better......and probably powershell as well.  Thanks again.

    Be kind and Mark as Answer if I helped.


    Nope - works exactly the same in VBScript and in PowerShell.

    ¯\_(ツ)_/¯

    Wednesday, March 26, 2014 2:21 PM