Lately working with one of the customer’s I came across an interesting lookout.

Basically customer has created a simple workflow for SharePoint in Visual Studio 2008 and had used a delay activity which seems to be causing the problem.

The problem was that workflow runs perfectly fine but after hitting the delay activity, never wakes up.

My first hunch went to the issue with SharePoint Workflows with delay activities (also noted on SharePoint Product Group blog). But the workflow seems to be too simple to get into any of the known issues.

Now I started looking into the deployment of the workflow and noticed that they have deployed the workflow’s assemblies into the BIN folder of the IIS-App under c:\inetpub.

Well, it does not seems to be the problem as the workflow was starting up fine and going through a few activities and facing issue only when hitting the delay activity.

The workflow architecture training earlier came to my rescue.

Basically workflow in 2 different process.

- W3WP.exe

W3WP.exe is the ASP.net worker process. When you first start the workflow (automatically or manually), the workflow assembly is loaded and workflow started by W3WP.exe process.

OWSTIMER.exe comes into picture when the workflow is persisted into the database and need to be woken up and restored into the memory.

In this particular scenario of the customer, the workflow assemblies were there in BIN of the IIS-Application under C:\InetPub folder. Now W3WP.exe process recognize which locations to scan for and from where the assemblies need to be picked up. But once the workflow hits the Delay Activity and it is saved to the database, to wake it up and restore into the in-memory state and continue execution, OWSTIMER.exe does not know the location of the assemblies, therefore the workflow fails to wake up.

Finally the resolution: 
Once we determined the problem, suggested the customer to sign the workflow assemblies and deploy them to GAC and remove from the BIN folder of the IIS-Application. Once the changes were done and assemblies deployed to GAC, the workflow worked perfectly fine and  completed “as expected”.

Hope this small in-sight helps someone out there with their workflows

Comments (7)
  1. This sounds similar to an issue I have. In my case, I want the delay (timer placed on the queue) to come back on the same thread as I have a synchronous workflow. If it continues on a new process or thread then I won’t get a response on the original calling thread. Any ideas?


  2. Sergei says:

    Run into the same problem. Somehow the workflow does not wake up and does not load itself back to the runtime..

  3. @Rory, thats right. The workflow is woken up by OWSTIMER.exe rather than W3WP.exe from sleep. So synchronous stuff will not work here.

    You can check synchronous event handlers if they would fit your requirement.

  4. @Sergei, your best bet here would be to check the ULS logs for any exceptions or errors as to why workflow is not loading back.

    Also you can enable workflow trace and see where it is failing. Details are covered under "Enabling workflow logging" section of http://msdn.microsoft.com/en-us/library/ms732240.aspx

  5. arWINdh says:

    I am facing this problem…………..

  6. I have the same problem with the delay activity that the workflow never get wake up. And the solution is already deployed in to the GAC and still have the problem. Can anyone one the cause for this problem? Thanks

Comments are closed.

Skip to main content