none
Task Engine failed to start

    Question

  • Strange goings on, I tell you. I've got a Windows Server 2008 Standard (x64) box running a couple tasks with secondary credentials. This task is very basic, it just calls a custom script every 15 minutes. However, the task has begun to fail with the following in the Event log:

    Log Name:      Microsoft-Windows-TaskScheduler/Operational
    Source:        Microsoft-Windows-TaskScheduler
    Date:          10/14/2009 4:28:36 PM
    Event ID:      311
    Task Category: Task Engine failed to start
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      name.domain.com
    Description:
    Task Scheduler failed to start Task Engine "S-1-5-21-2601602731-4105866543-3655554989-6874:DOMAIN\USER:Password:LUA"  process due to an error occurring in "EngineConnect" . Command="taskeng.exe" . Additional Data: Error Value: 2147942658.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-TaskScheduler" Guid="{de7b24ea-73c8-4a09-985d-5bdadcfa9017}" />
        <EventID>311</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>311</Task>
        <Opcode>101</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2009-10-14T23:28:36.995Z" />
        <EventRecordID>525860</EventRecordID>
        <Correlation />
        <Execution ProcessID="332" ThreadID="1140" />
        <Channel>Microsoft-Windows-TaskScheduler/Operational</Channel>
        <Computer>name.domain.com</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData Name="TaskEngineProcessLaunchFailed">
        <Data Name="TaskEngineName">S-1-5-21-2601602731-4105866543-3655554989-6874:DOMAIN\USER:Password:LUA</Data>
        <Data Name="Command">taskeng.exe</Data>
        <Data Name="ErrorDescription">EngineConnect</Data>
        <Data Name="ResultCode">2147942658</Data>
      </EventData>
    </Event>

    If I restart the computer, open the task and re-enter the credentials, it will run fine for about a month, then it just starts failing with this same message.

    I can run the script fine manually with the provided credentials.

    Would greatly appreciate any help! Thanks.
    Thursday, October 15, 2009 11:49 PM

Answers

  • Hi Matt,

     

    As the scheduled task failed to be run with non system and non admin domain credentials, I suggest you apply this hotfix in KB953153 onto the problematic server.

     

    Error message when you change the running user context of a scheduled task to another domain account on a computer that is running Windows Vista or Windows Server 2008: "The specified account name is not valid"

    http://support.microsoft.com/kb/953153

     

    Afterwards, please try restarting the computer to see if the issue can be fixed.

     

    Hope it helps.

     

    Best Regards,

    David Shen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by David Shen Monday, October 26, 2009 2:23 AM
    Monday, October 19, 2009 9:07 AM

All replies

  • Hi Matt,

    Thank you for posting in windows forums,

    With out restarting the OS , can you launch the script with administrator and check if the problem persists , also what does your script do ?


    sainath !analyze
    Friday, October 16, 2009 2:55 AM
  • Hi Matt,

     

    "Task Engine failed to start" error could be caused by the "Stop if the computer ceases to be idle" option is not saved. In order to resolve it, please refer to the KB950363 that Dave Patrick mentioned and  apply the hotfix in the document on the problematic server.

     

    KB 950363 The "Stop if the computer ceases to be idle" option is not saved for tasks that are configured for Windows Server 2003, Windows XP, or Windows 2000 in Windows Server 2008 or Windows Vista when triggers are enabled for the task


    http://support.microsoft.com/default.aspx?scid=kb;en-us;950363

     

    After applying the hotfix on the problematic server, please restart it and test to see if it works.


    If the issue still continues, please collect the following information.

    1.  Does this issue exist for all schedule tasks or some specific tasks? Please let the customer create a new schedule task to see whether this issue exists.

    2.   If possible, please reboot the server and then test this issue again.

    3.   Please verify that the following is enabled:

    a. Click Start, click Run, type gpedit.msc , and then click OK.

    b. Under Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then expand Security Options.

    c.  In the Policy pane, right-click Network access: Do not allow storage of credentials or .NET Passports for network authentication, click Properties, click to select Disabled, and then click OK.

    d.  Click Start, click Run, type regedit , and then click OK.

    e.  Locate and then right-click the following registry subkey:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

    f. Verify that the disabledomaincreds value is set to 0.

    g. Restart the computer.

    Best Regards,
    David Shen


    This posting is provided "AS IS" with no warranties, and confers no rights.

    • Edited by David Shen Monday, October 19, 2009 7:42 AM
    Friday, October 16, 2009 6:05 AM
  • Dave and David:

    KB 950363 Doesn't apply. The task is configured for Server 2008 and the "Stop if the computer ceases to be idle" option is not being used. The Security policy is already correct and the registry key "disabledomaincreds" value is already 0.

    Sainath:

    Yes, I can run the script manually (as the domain user via the command line, needs to run with specific creds, not Administrator). This particular script maps a drive (samba share on a Gentoo box), copies data, removes the drive map.

    This is happening for all tasks that are running with separate, non system, non admin domain credentials.
    Thanks for the responses.

    Other thoughts?
    Friday, October 16, 2009 3:41 PM
  • Hi Matt,

     

    As the scheduled task failed to be run with non system and non admin domain credentials, I suggest you apply this hotfix in KB953153 onto the problematic server.

     

    Error message when you change the running user context of a scheduled task to another domain account on a computer that is running Windows Vista or Windows Server 2008: "The specified account name is not valid"

    http://support.microsoft.com/kb/953153

     

    Afterwards, please try restarting the computer to see if the issue can be fixed.

     

    Hope it helps.

     

    Best Regards,

    David Shen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by David Shen Monday, October 26, 2009 2:23 AM
    Monday, October 19, 2009 9:07 AM
  • Hi Matt,

    Do you have a chance to apply this update? Is it helpful for you?

     

    Please keep us posted on your progress and let us know if you have any additional questions or concerns.


    We are looking forward to your response.

     

    Best Regards,

    David Shen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Proposed as answer by Sachin yelmar Wednesday, October 05, 2011 9:38 AM
    Friday, October 23, 2009 2:56 AM
  • Hi,

    If on your machine the schedules failed due to "task engine failure" then follow the following steps:-

     

    1.Uninstall the product.

    2.Reboot the machine.

    3.Fresh install the product.

    4.Now,try schedules with "amandabackup"  user.

    (I did above steps on my win-7 machine & my schedule worked fine with "amandabackup" user.

     

    Thanks,

    Sachin yelmar

    QA Engineer

     

    Wednesday, October 05, 2011 9:49 AM
  • For what it's worth, I ran into this same problem with a scheduled task, and it ended up being I did not have the proper domain authentication set in my users group.

    I followed this:

    http://support.microsoft.com/kb/970879

    and added the domain account that I was using also to the users group and that resolved my issue.

    Tuesday, August 07, 2012 2:28 PM