The default error handling in WF 3.5 is a bit of a pain point IMHO. Basically when an unhandled exception occurs in a workflow that WFI (WF instance) will be terminated and can’t be restarted. The model that you use to handle exception in WF is through fault handlers in your WF definitions in the same way you would use exception handlers in a non-WF program. This is not always desired and in many cases it’d be preferred to be able to abort the WFI instead which allows for you to retry the activity that threw the exception. For example say you have an activity that updates the DB that fails because the connection to the DB was down, you wouldn’t want to have to restart your workflow and then try and get it back to the same state it was in, it’d be much better to have it abort and restart from the same point when you load it again. In WF 4.0 they have moved to aborting WFIs when an exception is thrown and my current project required this kind of behavior which I was able to achieve with some help from jimblust on the WF forum who told me about the technique in this article. He came up with it but never used it himself because he felt it was too much of a hack but my requirements called for this behavior so I used it.