cancel
Showing results for 
Search instead for 
Did you mean: 

The infamous "failed to run" errors in the history list.

Not applicable
14 8 23.5K

Symptoms

You may have seen following error "[workflow name] failed to run" in the workflow history list of your workflow. The strangest part being the workflow runs successfully despite the errors displayed. This generally happens when the workflow enters a "dehydrated" or "paused" state.

051012_1935_pausedworkf1.png

Upon reviewing the ULS logs for this workflow you may find the following messages:

OWSTIMER.EXE (0x0E5C) 0x2184 SharePoint Foundation Workflow Infrastructure 72fu Unexpected Load Workflow Class: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.SharePoint.Workflow.SPWinOeHostServices.EnsurePluggableServices(SPSite site, SPWorkflowExternalDataExchangeServiceCollection services, ExternalDataExchangeService existingServices) at Microsoft.SharePoint.Workflow.SPWinOeHostServices..ctor(SPSite site, SPWeb web, SPWorkflowManager manager, SPWorkflowEngine engine)

OWSTIMER.EXE (0x0E5C) 0x2184 SharePoint Foundation Workflow Infrastructure 98d8 Unexpected System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.SharePoint.Workflow.SPWinOeHostServices.EnsurePluggableServices(SPSite site, SPWorkflowExternalDataExchangeServiceCollection services, ExternalDataExchangeService existingServices) at Microsoft.SharePoint.Workflow.SPWinOeHostServices..ctor(SPSite site, SPWeb web, SPWorkflowManager manager, SPWorkflowEngine engine)

OWSTIMER.EXE (0x0D64) 0x0E98 SharePoint Foundation Workflow Infrastructure frg9 Medium Workflow could not be run because SPWebApplication.UpdateWorkflowConfigurationSettings was not previously called, and the Web Application service has been disabled on this server. Call UpdateWorkflowConfigurationSettings or turn on the Web Application service for this server.

Cause

Farm Topology:

Service Applications 05.png-700x0.png

When a workflow has been queued for resumption and the Application server with the “Microsoft SharePoint Foundation Workflow Timer Service” tries to resume the workflow, it fails to run due to not having the “Microsoft SharePoint Foundation Web Application” service enabled. This error occurs because the Workflow Timer Service tries to read the workflow settings from the web.config or configuration database for the web application. By default, the workflow settings are stored in the web.config file of the server that is running the “Microsoft SharePoint Foundation Web Application” service.

When running workflows on application servers that are not configured to be front-end servers, the Workflow Timer service requires workflow configuration settings in Web.config to be set in the configuration database. This must be done through a script that calls UpdateWorkflowConfigurationSettings() on the SPWebApplication object, which will copy the Web.config settings from a front-end server. The script can be found below in the Microsoft recommended solution.

Resolution

We recommend stopping/starting the services on the servers in your farm that should/should not be running them. In order to avoid Nintex licensing errors we recommend you review you Nintex Workflow License and ensure your farm topology matches your license and adjust your services accordingly. To assist you with this process please refer to and follow this article: Workflows and the SharePoint services required to run them​.

Microsoft recommends the following to resolve these "Failed to run" errors:

Method 1)

Locate one Web Front End server which has Web Application service running, run the following PowerShell command to copy workflow-related configuration from the web.config to the configuration database so it will be available from every server in the Farm.

$webapp = Get-SPWebApplication -identity http://<web app name>

$webapp.UpdateWorkflowConfigurationSettings()

Method 2) Start the Web Application Service on all servers that have the Workflow Timer Service running.

Method 3) Disable the Workflow Timer Service on servers that are not running the Web Application service.

(Source: https://support.microsoft.com/en-us/kb/2674684​)

Please note: the “Microsoft SharePoint Foundation Web Application” service provides web server functionality. Starting or stopping this service will deploy/remove files from the C:\inetpub\wwwroot\ directory. Please perform this action at your own discretion.

8 Comments
ganesh_lathi
Nintex Newbie

We had this issue over the weekend after installing the nintex forms and workflow upgrade. Nintex state machine workflows were stuck. Tried all the steps you mentioned above but that did not really helped. As a final resort we had to do sharepoint timer service restart on all the app and wfe servers. That resolved our issue. Thought of sharing this in case someone has a similar issue after upgrading Nintex.

jherschel
Nintex Newbie

We just had this issue.  We started the Workflow Timer Service on an application server (that's what app servers are for, right? ), but we realized that since Web application service wasn't running, we then got a whole bunch of Nintex Workflow error notifications and all worfklows had the [Workflow Name] failed to run error at the time we started the service.  We quickly stopped the service, but damage was done, only in our case, it appeared the workflows did not resume or after the next step they failed, for instance, we saw the timestamp at time where [Workflow Name] failed to run, but a step after a task was completed, the next step was Error in task, user is no longer required to review the form., error occurred in this workflow.NintexWFERror.png

This is also similar to this: Workflows and the SharePoint services required to run them

Not applicable

Jonathan,

The failed to run messages are more than likely separate from your workflow failures. The ULS logs on your SharePoint farm will reveal the true reason behind the failure in the related call stack. I always recommend reviewing the call stack over the history list errors. It's the difference between the check engine light and a code reader in vehicle mechanics.

To be more clear, the "failed to run" messages indicate that this workflow was queued on a server that could not resume this workflow. Once this happens it is sent back to the "dbo.ScheduledWorkItems" table where it will be picked up by another available server running the "Microsoft Foundation Workflow Timer Service" to resume this workflow. Which ever server picks up the workflow next is dependent on which server is the least busy at the time.

If the only server available to run the workflow is the failing server then the workflow would error out. I am not 100% certain on the number of failures a workflow can encounter before SharePoint will set it to an errored state but I am aware that it will terminate the workflow after a number of failures.

Let me know if this helps answer your question.

Cheers,

Andrew Beals

Not applicable

Ganesh,

A recycle of the "SharePoint Timer Service" would simply re-queue all time jobs running on your servers. If restarting the SharePoint timer services on your local servers resolved the issues you were experiencing, this would indicate a stuck "workflow" timer job on one of these servers. I would recommend investigating why a "workflow" timer job has halted on one of your servers and if you continue to see these failures.

Cheers,

Andrew Beals

Not applicable

Bhuti,

Woot! Glad to hear this helped somebody out there!

Cheers,

Andrew Beals

jherschel
Nintex Newbie

Thanks, helps a lot.

jpmhuls
Nintex Newbie

Hi Andrew, just found this article following an issue where an approved/rejected flexi task was set to Canceled and the workflow errored, with the "... failed to run error" (14/04/2018 06:51) workflow history entry just prior to the crashing of the workflow. The resulting error message was "Error in task. Unauthorized attempt to update workflow task by <userid>. The response has not been recorded." (14/04/2018 06:57). However the user has proper permissions and at other times the approval workflow works just fine for the involved user.

Could this indeed affect any task being approved/rejected?

Warwick
Nintex Newbie

Great overview, glad these posts aren't deleted once a support member leaves the company.