I am experiencing a very weird behavior: After using SPListItem.Update() the OnWorkflowItemChanged is triggered (so the title is misleading), but sends the workflow into a sleep state it never wakes up from...

I have a list workflow running on a list item. It actually is a test workflow containing only a OnWorkflowItemChanged Activity as well as a Code Activity:

enter image description here

Within the code activity is only a breakpoint so I can tell when it is being hit.

I go ahead and associatiate the workflow to a custom item list and manually start the workflow on one item.
Here comes the funny part:

  1. When going via the UI, making any change to my item (e.g. change the Title from "Goodbye" to "Hello") and saving, the workflow continues as it should --> it hits the breakpoint and afterwards finishes gracefully.
  2. When using the Object model to update the item the workflow gets stuck in the "queued" state (Due to heavy load, the latest workflow operation has been queued. It will attempt to resume at a later time.) --> the breakpoint never gets hit

I run the following code in a seperate console app to update the item:

using (SPSite spSite = new SPSite("http://SP2010"))
    using (SPWeb spWeb = spSite.RootWeb)
        SPList list = spWeb.GetList("/Lists/TestList");
        var listItem = list.GetItemByUniqueId(new Guid("<myguid>"));

        listItem["Title"] = "Hello";

The list item is actually updated (the title changes) and the workflow is "triggered" as in it goes into the queued state - but it never moves forward and never comes out of its sleeping beauty state. There is no way to revive the workflow by e.g. changing the list item again via the UI - it's just dead.

Is there anything I'm doing wrong by just calling listItem.Update()? I already tried list.Update() and listItem.SystemUpdate() but besides that I don't know why the workflow goes into this weird state for such a simple thing.

Update: I tried giving the OnWorkflowItemChanged a method invoked - even a breakpoint in that method is not being hit (of course it is being hit when using the UI to update the item).

2 Answers 2


Did you check if you are updating the item as a system account?

Try starting the console app as a "normal" user please. Updates made by the system account do not trigger workflows.

  • Sorry I could not reproduce my problem - maybe I was executing the code as a System account.
    – Dennis G
    Jun 30, 2011 at 8:18

If the workflow action gets queued; the code will potentially run in a separate process to the one that is being debugged by Visual Studio (especially if you're using F5 deploy with VS2010). Are you sure the code is not being run outside of the context of the process that you are debugging. Check by attaching to the correct worker processes using Debug -> Attach to Process.

  • It definitely is the process I am debugging - when I put a breakpoint before the OnWorkflowItemChanged event - it will be hit. Same goes for manually changing the item via the UI - breakpoint will be hit.
    – Dennis G
    Apr 20, 2011 at 14:38
  • Also debugging is a non-issue! Even when not debugging and having the workflow deployed regularly it just gets stuck in the queued mode.
    – Dennis G
    Apr 20, 2011 at 14:44
  • My mistake - I reread your question and see that you have clarified that - I just assumed you thought it wasn't running because the breakpoint wasn't being hit! Apr 20, 2011 at 14:49
  • @moontear Instead of putting a breakpoint can you setup the debugger to break on all C# exceptions? You might get to see the exception in whichever thread it might be.
    – sumitkm
    May 14, 2011 at 7:15
  • @moontear I am assuming when you are making the list update through UI, the user has permissions to initiate workflow.
    – sumitkm
    May 14, 2011 at 7:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.