locked
SPD2010 Workflows causing SP2013 indefinitely crash after publishing error RRS feed

Answers

  • This issue has been submitted as a bug to the .NET framework product team by the Microsoft escalation engineers working our premiere support ticket.  

    When the error occurs, the associated application pool service account's temp folder gets deleted.  Recreating the 'Temp' folder in the following path fixes the errors without having to restart the application pool.
    Path: C:\Users\<service-acct>\AppData\Local\Temp

    An alternate workaround is to create a read-only file within the Temp directory so that it cannot be deleted.

    marcadamcarter

    Sunday, May 25, 2014 5:58 AM

All replies

  • Hi,

    According to your post, my understanding is that you got an error when publish the SharePoint 2010 workflow using SharePoint designer 2013.

    You can add executionTimeout property in web.config file to increase the timeout interval(Make a copy of the web.config file before editing anything).

    For more information, please refer to this site:

    Fixed: SharePoint Designer Error - Unexpected error on server associating the workflow:http://www.manjuke.com/2011/05/fixed-sharepoint-designer-error.html

    You can also start the “App Management Service” to check whether it works.

    More references: http://wp.ahcheng.com/2013/03/23/error-were-found-when-compiling-the-workflow-the-workflow-files-were-saved-but-cannot-be-run/

    http://sharedpointing.wordpress.com/2009/09/21/sharepoint-designer-errors-were-found-when-compiling-the-workflow/

    Thanks & Regards,

    Jason

    Jason Guo
    TechNet Community Support

    Wednesday, March 12, 2014 5:42 AM
  • Jason,
    Thanks for the response.

    Not sure I follow your suggestion on increasing the timeout interval or how you arrived at it.  Can you please explain.

    We did not previously have the “App Management Service” provisioned on the farm but I’ve since created and started.  However this did not correct or appear to have any positive impact on the problem.

    To reiterate, the problem only occurs whenever an invalid or workflow that contains a logic-error is published.  Once that process happens the only route we have found to “fix” secondary SPSite issues (as described previously) is to perform an IISRESET.  One obvious answer would be “not to publish invalid workflows”.  But we cannot assure this will not happen. 


    marcadamcarter

    Wednesday, March 12, 2014 5:01 PM
  • Providing further details we've recently identified to hopefully elicit further feedback on this issue as it remains unresolved.

    The issue appears to be limited to web application.  Publishing an inerror (or invalid) workflow to Wep App (A) will not cause any disruption on Web App (B).  Likewise if we publish an inerror workflow to Web App (B), Web App (A) will not be impacted.  Recycling only the web app will correct the problem until the next time.


    marcadamcarter

    Tuesday, March 25, 2014 9:56 PM
  • More details...

    • Loaded an instance of SPS 2013 RTM (15.0.4420.1017) and unable to reproduce the problem
    • Upgraded to SP1 and problem occurs

    We're now going to try reverting back to RTM and progress through the build releases to see if/when the problem occurs.  Hoping to elicit further feedback on this issue as it remains unresolved and now appears to 


    marcadamcarter

    Thursday, April 3, 2014 1:56 AM
  • Latest details...

    • Reverted environment back to SPS 2013 RTM (15.0.4420.XXXX) - unable to reproduce the error.
    • Upgrade to March 2013 PU - able to reproduce the problem (once a workflow compilation error is produced, due to logic error within the WF, all subsequent attempts to publish valid workflows fail and various site settings pages fail until the associated Web App is recycled).
    • Upgrade to SP1 2014 - problem still exists (same as above)

    Analyzing SPS .dll's (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI\) I would have to rule out the problem being associated with "Microsoft.SharePoint.WorkflowActions.dll" as FileVersion were identical on both RTM (working) & March2013 PU (not)

    • 15.0.4420.1017 - Both RTM & after MAR-2013 PU
    • 15.0.4545.1000 - after SP1

    "Microsoft.SharePoint.Client.WorkflowServices.dll"

    • 15.0.4420.1017 - RTM (working)
    • 15.0.4454.1000 - after MAR-2013 PU (not)
    • 15.0.4553.1000 - after SP1 (not)

    Just to reiterate, we haven't configured/installed Workflow Manager and are relying on OOB SP2010 WFs.  Hoping to elicit further feedback on this issue as it remains unresolved.  Feedback/Comments appreciated.


    marcadamcarter

    Thursday, April 3, 2014 8:39 PM
  • Posting example steps to reproduce error:

    Simple workflow with invalid logic.  Example below demonstrates how we can reproduce the error.

    Creating WF error

    As you can see from the image below, the WF logic step is Deleted but the placeholder remains.

    Workflow with empty placeholder

    The workflow passes validation check but errors out when attempting to publish.  Once this happens no subsequent workflows can be published, resulting in error "Errors were found when compiling the workflow. The workflow files were saved but cannot be run: Unexpected error on server associating the workflow."


    marcadamcarter

    Friday, April 4, 2014 9:01 PM
  • This issue has been submitted as a bug to the .NET framework product team by the Microsoft escalation engineers working our premiere support ticket.  

    When the error occurs, the associated application pool service account's temp folder gets deleted.  Recreating the 'Temp' folder in the following path fixes the errors without having to restart the application pool.
    Path: C:\Users\<service-acct>\AppData\Local\Temp

    An alternate workaround is to create a read-only file within the Temp directory so that it cannot be deleted.

    marcadamcarter

    Sunday, May 25, 2014 5:58 AM