- Remove From My Forums
-
Question
-
I have an old Designer-created custom workflow that required the addition of a new condition/action. I edited it and when I clicked the Finish button, I received: Unexpected error on server associating the workflow .
I tried adding the timeout attribute in the web.config that I have seen mentioned in articles on the web, but no luck. I see no other solutions suggested. Anyone have any idea how I might get past this?
There are no mistakes; every result tells you something of value about what you are trying to accomplish.
Answers
-
Hi run4it,
If this problem only occurs on once certain web application, copy the web.config file from another web application which works well. After that,
clear SharePoint Designer assembly cache and reset IIS. Then check if problem still exists or not.
Don’t forget to do copy of the original web.config file of the problem web application.
If the problem resolved by using the new web.config file, check out the difference in the old and new web.config files, that should be the problem.
If the problem still exists, could you find more error details from ULS log?
Thanks & Regards,
Emir Liu
TechNet Subscriber Support in forum
If you have any feedback on our support, please click
here.
Emir Liu
TechNet Community Support
-
Marked as answer by
Wednesday, January 23, 2013 4:42 PM
-
Marked as answer by
| title | description | ms.date | ms.prod | ms.assetid | ms.localizationpriority |
|---|---|---|---|---|---|
|
Common error messages in SharePoint workflow development |
A listing of common error messages that you might encounter while developing SharePoint workflows and guidance for solving the underlying problem. |
09/25/2017 |
sharepoint |
e9bf6878-c722-4b1f-b5b5-b302ae0ea4da |
high |
Common error messages in SharePoint workflow development
A listing of common error messages that you might encounter while developing SharePoint workflows and guidance for solving the underlying problem.
[!NOTE]
SharePoint 2010 workflows have been retired since August 1, 2020 for new tenants and removed from existing tenants on November 1, 2020. If you’re using SharePoint 2010 workflows, we recommend migrating to Power Automate or other supported solutions. For more info, see SharePoint 2010 workflow retirement.
Common SharePoint workflow errors
Although this list doesn’t cover every possible error you may encounter when developing SharePoint workflows, it does cover those that you are most likely to face.
-
Timeout while waiting for sandboxed code execution request to complete within the worker process
-
Timeout while waiting for request to complete within the sandboxed appdomain
-
The worker process handling this request was ended because it exceeded the resource {0}
-
This workflow could not run because a sandboxed solution encountered an error
-
This workflow could not run because the sandbox failed: Could not get a process from the process pool
-
This workflow could not run because the sandbox failed: The sandboxed code worker process exited unexpectedly
-
The e-mail message cannot be sent. Make sure the outgoing e-mail settings for the server are configured correctly
-
The e-mail message cannot be sent. Email non-delivery reports in Exchange Online
-
The workflow could not update the item, possibly because one or more columns for the item require a different type of information
-
The workflow operation failed because the workflow lookup found no matching item
-
The workflow could not create the list item because the file name is either missing or invalid
-
Coercion Failed: Unable to transform the input lookup data into the requested type
-
The workflow operation failed because the action requires the document to be checked out
-
Errors were found when compiling the workflow. The workflow files were saved but cannot be run. Unexpected error on server associating the workflow
Timeout while waiting for sandboxed code execution request to complete within the worker process
Same issue and same solution as the item below, «Timeout while waiting for request to complete within the sandboxed appdomain».
Timeout while waiting for request to complete within the sandboxed appdomain
Both of these errors result from the same issue—exceeding the default timeout period for the workflow action to execute. The default timeout period is 30 seconds.
You can change the timeout value in on-premises installations, but you can’t change it in SharePoint Online installations. To avoid getting this error in SharePoint Online installations, you must modify your code to limit actions in the worker process or appdomain to fewer than 30 seconds.
To modify the timeout period in your on-premises installation, execute the following Windows PowerShell command. Note that the example code resets the timeout to 60 seconds, but you can use another value.
Add-pssnapin microsoft.sharepoint.powershell
$userCodeSvc = [Microsoft.SharePoint.Administration.SPUserCodeService]::Local
#change to 60 second timeout
$userCodeSvc.WorkerProcessExecutionTimeout = 60
$userCodeSvc.Update()
The worker process handling this request was ended because it exceeded the resource {0}
In the error string, the value of {0} is a placeholder for the specific resource whose threshold has been exceeded. To alleviate this problem, you should modify your code so that it does not exceed the resource threshold. These resource values are documented in Resource Usage Limits on Sandboxed Solutions in SharePoint 2010.
This workflow could not run because a sandboxed solution encountered an error
The workflow code threw an unhandled exception. Resolving this error requires debugging and revising your sandboxed code.
This workflow could not run because the sandbox failed: Could not get a process from the process pool
There is an error in your sandbox configuration. For information about configuring a sandboxed solution, see Sandboxed Solutions in SharePoint.
This workflow could not run because the sandbox failed: The sandboxed code worker process exited unexpectedly
There is an error in your sandbox configuration. For information about configuring a sandboxed solution, see Sandboxed Solutions in SharePoint.
The e-mail message cannot be sent. Make sure the outgoing e-mail settings for the server are configured correctly
There are two issues of note to consider when troubleshooting email issues. In both on-premises and SharePoint Online installations, ensure that all addresses on the To: and Cc: lines are valid email addresses. In on-premises installations, ensure that email settings on the server are configured correctly.
Review the following to ensure that you have correctly configured incoming and outgoing emails.
- Deployment guide for Microsoft SharePoint
Errors sending e-mail can also happen because of Exchange non-delivery. Review the following to ensure that you are not having this issue:
- Email non-delivery reports in Exchange Online
The workflow could not update the item, possibly because one or more columns for the item require a different type of information
This error commonly results from one of two situations:
-
One of the list fields was removed or changed, but the workflow was not updated to account for the change and is therefore trying to set a value for the old field. You should check all Update List Item actions in your workflow and make sure they are setting appropriate values for fields and that those fields exist on the list.
-
There is a data type error wherein the workflow is trying to set a value in a field in the list item using the wrong data type. You should confirm that the Return Field As operation in their lookup is of the correct data type.
The workflow operation failed because the workflow lookup found no matching item
This indicates there is an error in the workflow logic. Check to ensure that you are selecting the correct list and field in your lookup.
The workflow could not create the list item because the file name is either missing or invalid
This indicates there is an error in the workflow logic. Ensure that the file name entered in the Path and Name field is a valid file name. Common reasons for a file name to be invalid include a missing or incorrect file extension or a file/path string that is too long and exceeds the allowable number of characters.
Coercion Failed: Unable to transform the input lookup data into the requested type
The operation failed to cast values between incompatible data types (for example, converting a random string to a Date/Time value). You should check the Return Field As settings in your lookup to ensure that it is a valid data type for the expected data.
The workflow operation failed because the action requires the document to be checked out
You must check out the item using the Check Out Item action before using the Update Item action.
Errors were found when compiling the workflow. The workflow files were saved but cannot be run. Unexpected error on server associating the workflow
See Microsoft Support Knowledge Base article ID 2557533 ( https://support.microsoft.com/kb/2557533) for more information.
See also
-
SharePoint workflow development best practices
-
Develop SharePoint workflows using Visual Studio
⛔️ Problem
If you have a LARGE (even with just a few Approval processes) SharePoint Designer 2010 workflow, you may come across an error stating that the workflow cannot be published with message «Errors were found when compiling the workflow. The workflow files were saved but cannot be run. Unexpected error on server associating the workflow.«.
This error keeps popping whenever you try to publish the workflow.
This error is known with SharePoint 2010 workflows, but can occur for other SharePoint versions as well.
As a developer, «Unexpected Error» is of no use for troubleshooting with SharePoint. So how do we go about?
SharePoint Errors were found when compiling the workflow
⚡️ Reason
The problem is caused by the large number of Types that are created during workflow compilation, for workflows with many local workflow variables.
It is more common for workflows with multiple Approval Process actions, as each reconfigured Approval Process Action comes with a large set of local variables, for the different configurable property of the Approval Process.
Prior to the February 2011 CU, limits on the complexity of the workflow definition were enforced by the Microsoft .NET 3.0 workflow compiler. With the February 2011 CU, SharePoint uses the SPWebApplication UserDefinedWorkflowMaximumComplexity property to enforce a maximum number of Types in the workflow definition, and prevent compilation in these cases.
⛏️ Fix
Make sure the February 2011 CU is installed.
This will make available the UserDefinedWorkflowMaximumComplexity property.
By installing a CU that includes the server February 2011 CU, SharePoint administrators are now able to prevent compilation of workflows whose compilation would affect the performance of the farm. The default value of the property is 7000, but can be changed based on the needs and profile of the SharePoint farm.
The following PowerShell (SharePoint Management Shell — Run as Administrator) script can be used to adjust the value per SPWebApplication —
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$new_limit = XXXX (Set the limit here as a number);
$webapp = [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup("http://WebAppURL")
$webapp.UserDefinedWorkflowMaximumComplexity = $new_limit
$webapp.Update()Try publishing the workflow now, will get through! — but takes some time due to heavy workflow (heavy for SharePoint 2010 Designer).
✔️ Tip
For large workflows, try to restructure and either have more reusable pieces, or break out into smaller individual small workflows.
Check if you have multiple versions of the same workflow and older items attached to it, remove older versions of the workflow if required after completing the in progress ones.
Have Questions? Post them here!
When attempting to publish a SharePoint Designer 2010 workflow that is large or uses multiple Start Approval Process actions, an error indicating that the workflow cannot be published will be displayed.
- SharePoint Designer will show the following error: “Errors were found when compiling the workflow. The workflow files were saved but cannot be run. Unexpected error on server associating the workflow”.
Cause
This problem is caused by the large number of Types that are created during workflow compilation, for workflows with many local workflow variables. It is more common for workflows with multiple Approval Process actions, as each pre-configured Approval Process Action comes with a large set of local variables, for the different configurable property of the Approval Process.
SharePoint uses the SPWebApplication UserDefinedWorkflowMaximumComplexity property to enforce a maximum number of Types in the workflow definition, and prevent compilation in these cases.
In my case, the workflow consists of 11th level of Approval process and it was not publishing successfully. Following screenshot illustrates the scenario:
Resolution
SharePoint administrators are now able to prevent compilation of workflows whose compilation would affect the performance of the farm. The default value of the property is 7000, but can be changed based on the needs and profile of the SharePoint farm.
The following PowerShell script can be used to adjust the value per SPWebApplication:
[System.Reflection.Assembly]::LoadWithPartialName(«Microsoft.SharePoint»)
$new_limit = 30000;
$webapp = [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup(http://WebAppURL)
$webapp.UserDefinedWorkflowMaximumComplexity = $new_limit
$webapp.Update()
To give context to the default 7,000 value a Start Approval Process action contains 1176 nodes, a Start Feedback Process action contains 1010 and an empty Start Custom Task Process contains 13 nodes.
After running the above PowerShell script successfully on my SharePoint Farm, the workflow published successfully.
Happy SharePointing……………………:)
One of the things I’ve always enjoyed in life is taking thing apart to see how they work. And while I thoroughly enjoy dismantling and then reassembling objects, it is discovering and understanding how things function internally that I find so satisfying. This is one of the aspects I love about what I do as a consultant.
Understanding how SharePoint works “under the covers” is one of the things I love to explore. Fortunately for me, I get to do this often when clients encounter problems they can’t solve themselves. This is what happened recently when a client approached me about a workflow that they could no longer publish.
For an unknown reason, my client began to experience unexpected worklow errors when publishing SharePoint 2010 workflows into SharePoint 2013 using SharePoint Designer (SPD). While my client had not had problems publishing workflows in the past, they now could only save their workflows — they could not publish them. Now any attempt to publish their workflows resulted in the following error in SPD:
Workflow Error
Errors were found when compiling the workflow. The workflow files are saved but cannot be run. Unexpected error on server associating the workflow.
Initially, because saving the workflow took longer than I expected or wanted, I thought the error was a result of the complexity of the workflow itself. However, as I explored that posibility, I noticed that SharePoint Designer was able to validate the workflow successfully. Still, I just didn’t believe that the workflow was actually compiling given that it was a declarative “no code” SharePoint Designer workflow. I’m used to seeing “compiling” associated with code-centric workflows built and compiled in Visual Studio.
But of course, since SharePoint Designer did not paired the error with a correlation id, I couldn’t use the Merge-SPLogFile PowerShell cmdlet to quickly find additional information in the ULS logs. Thus, I went hunting in the ULS logs based on when I generated the error in SPD. And, after a short while I discovered the smoking gun:
01/12/2016 16:49:02.56 w3wp.exe (0x29C0) 0x3758 SharePoint Foundation Legacy Workflow Infrastructure xmfh Medium Workflow Compile Failed: Could not find a part of the path ‘C:UsersspsvcAppDataLocalTemppbaoxqic.tmp’. afa6549d-73bc-40b9-6996-656d6aa52194
Sure enough, SharePoint’s attempt to compile the workflow failed because it couldn’t find a file. I learned a couple new things about how SharePoint works. First, SharePoint compiles declarative SPD workflows and second, it does it using the web application pool identity account in a temporary location. In fact, as I explored the MSDN documentation I came across this statement:
A compiled workflow is stored on a server running SharePoint Server 2010 as a precompiled dll file whereas a declarative workflow is deployed on a server running SharePoint Server 2010 as an Extensible Object Markup Language (XOML) file and compiled in the content database each time an instance of the workflow is started.
And so I checked the file path I found in the ULS log details and confirmed that indeed the expected path did not exist! I then used the service account to recreate the AppDataTemp directory and tried to publish the workflow again. That did it, the workflow published successfully.
But, all this did not explain why the Temp folder was deleted in the first place. And while I didn’t have an answer for that question, I now had more information that led me to find a SharePoint Developer Support Team post that I had not found previously. The post describes the exact scenario and suggests using a read-only file in the Temp folder to prevent the deletion of the Temp folder in the future. So far so good, but I still want to know why it happened in the first place. Unfortunately, it looks like that will continue to be a mystery.