OWSTimer Debugger Annoyances

Applies To: SharePoint 2010, Visual Studio 2010

If you’re running Visual Studio on the same machine with SharePoint 2010 you are probably familar with this error message:

“An unhandled exception (‘System.Security.Cryptography.CryptographicException’) occurred in OWSTIMER.EXE [#]. The Just-In-Time debugger was launched without necessary security permissions. To debug this process, the Just-In-Time debugger must be run as an Administrator. Would you like to debug this process?”

In fact, you are probably very familiar with this dialog since it will pop up at least once a day. If you haven’t logged in in a while, then you will have multiple windows to cancel debugging in.

The problem is due to a threading issue related to an encryption key used by the OWSTIMER service. In SharePoint 2010 the timer service gets recycled daily (default is 6 AM) using a timer job mysteriously called “Timer Service Recycle”. The details aren’t all that important, but you can read more here and get even more information about how the mistake really occurs here. To summarize, the key isn’t found due to impersonation issues. (BTW, that number at the end of the error message is just the process ID and will change each time.)

Bottom line for me is that the error is not really a problem and can safely be ignored in your logs. The annoyance comes when you have Visual Studio installed and the JIT debugger is enabled.

You can either adjust your settings using the registry, or even better, just open up Visual Studio (2010) and adjust your options. Using the menu, choose Tools > Options. Then expand Debugging from the tree on the left (if it isn’t showing, check the Show all settings box) then choose Just-In-Time. To turn it off, just uncheck all the boxes and press OK:

Now those annoying messages will stop and the people will rejoice. Just remember that it can be very helpful to turn these back on when attempting to debug certain types of things (Custom Timer Jobs for instance), but be sure to bookmark this page because you will forget to turn it back off and then you will be sad again and I don’t want you to be sad.

LiquidOffice Retry on Exception

Applies To: LiquidOffice

LiquidOffice tasks can fail for a number of reasons. By default, a failed task halts the entire process and you will have to manually skip the task, delete the process or take some other action using Management Console. Sometimes, however, wouldn’t it be nice if the failed task waited a certain amount of time then retried?

We have found this to be especially helpful for web service tasks. Calls to web services can fail if the server has gone offline for a minute, but could recover if tried in 10 minutes or so. So we have added an exception loop to each of our web service tasks that retries indefinitely.

Here is the process:

On this process you can see we have a Form task and then a script task called FailTask. The FailTask is pretty simple, it just throws an exception. Here is the code inside the FailTask:

void enteredActive(State state) {
 Log log = LogFactory.getLog();

So we write a message to the log then try to set the value on a field that doesn’t exist. FAIL! The next task, Other Stuff, will never be reached in this particular example, but is representative of the rest of your process.

The other four tasks are the interesting ones. First is an Exception task. An exception task is just a task that becomes active when the task it is connected to (with a red line) throws an exception – pretty straightforward. After the exception task we have placed a Delay task. This is the task that determines how long the process should wait before retrying.

The most important task is the Reset State script task. Here is the code inside:

void enteredActive(State state) {

(This Code can also be placed in the Delay task on the enteringDone event, we have separated it into a separate Script task just to make it easy to understand)

This code retrieves the failed task (whatever task you are attaching the exception loop too) and sets its’ state to READY. This command will fail if the task is not currently at state ABORT, so just make sure to only put this code inside your exception loop.

The last member of this loop is the strangest, the Loop task. The loop task is between the Delay task and the Exception task and does NOT link back to the main process (Fail Task). Resetting the state of the Failed task immediately activates it (which is why we reset AFTER the delay task). The loop is only there to reactivate the exception task so that if the Failed task fails again, the exception loop starts over.

In our example above the process will retry forever until it succeeds. You could easily add conditions to the loop task to determine how often it should run and this will be the equivalent of a retry count (since the exception task will never be reactivated).

Adding these types of loops to your processes can help them to be more robust and keep you from having to intervene on recoverable tasks.

UPDATE: Although the above guide can be greatly improve the reliability of your processes, LiquidOffice isn’t not a very reliable program. Depending on a variety of factors, Exception tasks themselves can have exceptions and there’s really no way to totally prevent these.

Originally published on wirebear.com/blog on January 18, 2011