This is the second posting I’ve put together regarding OWSTimer.  In a previous post I had a client who simply pegged the timer by running a batch update against thousands of list items subsequently kicking off thousands of workflows.  In a more recent encounter, one of my clients called me with the OWSTimer again going mad, but for a completely different reason. 

Problem

OWSTimer.exe taking 100% CPU and/or creating Gigabyte sized log files.

Solution

Below  are the steps I used to troubleshoot the client’s environment with the actual screenshots.  In the end I believe that a simple stsadm –o execadmnsvcjobs did the trick.

Step 1- Check the logfiles, they are too big to open.

Step 2 – Are we out of drive space?

Step 3 – With permission from the client, stop "Windows SharePoint Services Timer”

Step 3 – Also stop the “Windows SharePoint Services Tracing” services

Step 4 – Review the log.  We clearly have timer job issues

Step 5 – Review the event log.  Hmm, note how the time changed?  Client confirmed that they had a time issue with the server a few weeks back.  Looks like we had daylight savings time kick in unexpectedly this morning.

Step 6 – Review the timer jobs.  Nothing significant to see

Step 7 – Let’s execute any pending jobs

Step 8 – Before we restart let’s turn off tracing so that we don’t keep filling up the log files (note that we do turn tracing back on later).

Step 9 – Restart the "Windows SharePoint Services Timer” and “Windows SharePoint Services Tracing” services

Step 10 – Re-run stsadm –o execadmsvcjobs

Step 11 – Check the timer service, CPU looks good!

Step 12 – Re-enable tracing

Explanation/Theory

Time change caused timer job to trigger because it thought it was the predecessor of a timer job already in the stack. Of course 2 timer jobs most likely tried to communicate or attach to the same object causing the server to spin into a loop. Large logfiles was simply a side effect (and the logs were behaving properly).

Popularity: 11% [?]