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:\Users\spsvc\AppData\Local\Temp\pbaoxqic.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 \AppData\Temp 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.