locked
Script or Executable Failed to Run RRS feed

  • Question

  • Good day guys,

    as most of you already experienced these types or errors (Script or Executable Failed To Run), I've isolated a common problem for these errors.
    A lot of these scripts rely on a path call "Monitoring Host Temporary Files (Insert Number here)"

    What I found is that for some reason, it tries to launch the script in that folder but the number changed..

    Exemple:

    Working Directory: C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 9\82\

    But directory is:
    C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 11\82

    This is very common.


    Here are my questions:

    When is this path created?
    Who creates it?
    How to change it?

    Once this question is resolve, a lot of these errors should go away as the problem is seldom in the scripts..

    Thanks!
    Tuesday, January 26, 2010 8:18 PM

Answers

  • As Marcin said before it is a nomal behavior that paths to files (which are mentioned in events log) do not exist.

    Let me explain how it works:

    1. Our execution engine executes some workflow (for instance, a discovery)
    2. If it is script-based then this script is copied to temporary path and executed there
    3. After execution (it does not matter whether it is success or failure) this temprorary file is not needed anymore and gets groomed (deleted)

    So, what possibly you see:

    1. Some workflow is executed
    2. It is script-based so script is copied to some new temporary folder
    3. Script is executed
    4. There is some problem so it reports failure
    5. Since execution engine does not need this script anymore it removes it
    6. This workflow is executed again
    7. Script is copied to new folder
    8. As a result we have an event log record with unexisting path and some other folder which actually has this file

    So, very likely that the behavior you described is not a root cause for these failures. The problem is in something else (and it might be different for every case).
    Thursday, February 4, 2010 7:24 PM

All replies

  • This is actually normal behavior. When the health service decides that it needs to run a script, it will save the script to one of the paths that you mention, run it with cscript and delete the script.

    What is happening in your case is that the script is executed (in the location from the alert), fails for some reason, and then is deleted along with the path. By the time, you get the alert, more scripts or other things probably ran causing more paths to be created and deleted (the number changes).

    It's more likely that the script failed for some reason.

    If you are running any custom scripts, they should not assume anything about the location they will be executed in.
    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    Thursday, January 28, 2010 7:15 PM
  • Hi

    One of the things I do here is to set an override to change the severity to informational. I also personalise the alert view to include the repeat count field.

    I then review the script errors every morning. If the script has failed 2 or 3 times in a day then in general it can be safely ignored. If the script has failed 100 times then it needs investigation.

    It would be preferable if this alert was generated after x consecutive failures ... at least then we'd only get an alert if it was an ongoing issue.

    To resolve this in more detail, you'll need to post the actual script name that is erroring ...

    Cheers

    Graham
    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Thursday, January 28, 2010 9:50 PM
  • Hi guys, glad to have a chat with you!

    Scripts that are failing are coming from standard management packs. Heres a few:

    Command executed: "C:\WINNT\system32\cscript.exe" /nologo "DiscoverAgentRelationshipSettings.js" 0 {F1C0619C-EC6D-ECA1-695E-F34348B39C4F} {6C02D697-48A3-385A-EEC9-1AAAC9C7E6E7} Working Directory: C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 3\1245\

    Command executed: "C:\WINDOWS\system32\cscript.exe" /nologo "MemoryUtilization.vbs" 2.5 2954.
    Working Directory: C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 8\247\

    etc..

    so I think there is a problem with the engine that launches theses scripts.

    I dont know whats the underlying process or whats keeping the old paths in memory...
    Thursday, February 4, 2010 5:28 PM
  • As Marcin said before it is a nomal behavior that paths to files (which are mentioned in events log) do not exist.

    Let me explain how it works:

    1. Our execution engine executes some workflow (for instance, a discovery)
    2. If it is script-based then this script is copied to temporary path and executed there
    3. After execution (it does not matter whether it is success or failure) this temprorary file is not needed anymore and gets groomed (deleted)

    So, what possibly you see:

    1. Some workflow is executed
    2. It is script-based so script is copied to some new temporary folder
    3. Script is executed
    4. There is some problem so it reports failure
    5. Since execution engine does not need this script anymore it removes it
    6. This workflow is executed again
    7. Script is copied to new folder
    8. As a result we have an event log record with unexisting path and some other folder which actually has this file

    So, very likely that the behavior you described is not a root cause for these failures. The problem is in something else (and it might be different for every case).
    Thursday, February 4, 2010 7:24 PM
  • Once an alert is created, the alert description stays the same. So the paths listed in your alerts existed when those alerts were created, but may have been removed afterwards.

    By the way, are you seeing alerts for the same scripts over and over (ignoring the path variations)? Are they from one machine or a particular set of machines?


    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    Thursday, February 4, 2010 7:24 PM
  • Hey Team,

    i See these Script or Executable Failed to Run errors on few of my production servers. This started after i deploy the latest OpsMgr R2 core MP updates version 6.1.7599.0

    1. on Win2003 server

    Alert: Script or Executable Failed to Run

    Source: prodweb05.com

    Path: prodweb05.com

    Last modified by: System

    Last modified time: 3/10/2010 6:22:20 PM Alert description: The process started at 6:22:08 PM failed to create System.PropertyBagData. Errors found in output:

     

    C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 12\4763\SCOMpercentageCPUTimeCounter.vbs(125, 5) SWbemRefresher: The remote procedure call failed and did not execute.

     

    Command executed:      "C:\WINDOWS\system32\cscript.exe" /nologo "SCOMpercentageCPUTimeCounter.vbs" pr0dweb05.com false 3

    Working Directory:         C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 12\4763\

     

    One or more workflows were affected by this.

     

    Workflow name: Microsoft.SystemCenter.HealthService.SCOMpercentageCPUTimeCollection

     

    Instance name: prodweb05.com

     

    Instance ID: {5DBF4902-E1D6-77EC-B6F2-6A26A37687EC}

     

    Management group: SCOM-Server01

    ++++++++++++++++++++++++++++++++++++++++++++++++++++
    2. on win2000 server

    Alert: Script or Executable Failed to Run

    Source: Prodweb35.com

    Path: Prodweb35.com

    Last modified by: System

    Last modified time: 3/10/2010 3:04:12 PM Alert description: The process started at 3:04:10 PM failed to create System.PropertyBagData. Errors found in output:

     

    C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 17\604\SCOMpercentageCPUTimeCounter.vbs(124, 5) Microsoft VBScript runtime error: ActiveX component can't create object: 'WbemScripting.SWbemRefresher'

     

    Command executed:      "C:\WINNT\system32\cscript.exe" /nologo "SCOMpercentageCPUTimeCounter.vbs" Prodweb35.com false 3

    Working Directory:         C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 17\604\

     

    One or more workflows were affected by this.

     

    Workflow name: Microsoft.SystemCenter.HealthService.SCOMpercentageCPUTimeCollection

     

    Instance name: Prodweb35.com

     

    Instance ID: {8D77F3E0-0AD5-30D0-40BE-917725ABEB19}

     

    Management group: SCOM-Server01

    not sure how to resolve these 2 different errors.

    -Vrkumar01

    Thursday, March 11, 2010 3:36 AM
  • We had the same issues with the SCOMpercentageCPUTimeCollection scripts, these eventually went away after a day or so.  Opened a brief thread on it here.
    Thursday, March 11, 2010 11:53 AM