Debugging Custom SharePoint Timer Jobs

SharePoint timer jobs are tasks executed on a scheduled basis by the Windows SharePoint Services timer service (owstimer.exe). They are analogous to scheduled tasks, and you can create them in any version of Windows, but SharePoint timer jobs come with many more benefits. SharePoint relies on timer jobs for a number of its functionality areas, and you can even broaden those functionalities and create your custom timer job to introduce new features.

For instance, last month I developed a custom timer job that runs on a daily basis to query all the SharePoint lists and libraries in all the site collections and insert corresponding records into a custom database table for reporting purposes.
Unfortunately, SharePoint timer jobs are tricky when it comes to debugging; it is not about attaching a debugger to w3wp.exe like what we did earlier in this issue. Troubleshooting my custom timer jobs has caused me a lot of headache; that is why I am determined to share with you all the tricks that I have learned in the course of developing a reporting timer job.
To debug custom timer jobs, follow these steps:

1. Insert an always-failing assertion statement at the beginning of the Execute method. You should use Debug.Assert(false) rather than Trace.Assert(false) since debug calls are detached from the release builds; then you don’t have to remove them from your code before moving to staging or production. 
2. Every time the timer job starts, you will get a pop-up window. This window hinders the execution of the timer job until you close the message box. Note that timer jobs run in parallel, so this window will never halt the execution of other timer jobs running simultaneously. For now, leave this window alone.
   
3. Select Debug > Attach to Process, and attach a debugger to the Windows SharePoint timer service (owstimer.exe). Make sure that the “Show process from all users” checkbox is selected if owstimer.exe is not listed.
   
4. Click the Ignore button in the assertion window.

There you go!

You might be wondering why you should insert the assert statement at the beginning of the Execute method of the timer job. It is true that you can just attach a debugger to owstimer.exe and wait for the subsequent cycle of the timer job, but it could be tough to find out whether the application has been effectively attached to the process since the jobs may not fire for several minutes. You could be left with Visual Studio attached to the owstimer.exe process with breakpoints set and wondering whether the job is running or wondering whether the breakpoints are not being hit because of some problem with loading the symbol files.