Debugging Custom SharePoint Timer Jobs

When you create a timer job for SharePoint 2010, you cannot directly press F5 to debug your code. Instead, you must attach the debugger to the SharePoint 2010 Timer process (Owstimer.exe). This how-to topic describes how to debug a timer job by attaching the Visual Studio debugger to the timer process.

Steps to debug a timer job in Visual Studio 2010

1. On the Start menu, point to Administrative Tools, and then click Services.
2. In the Services window, make sure the SharePoint 2010 Timer service is started(You can also restart this service to make the changes reflect in sharepoint server).
3. In your Visual Studio 2010 project that contains your custom timer job,set the break point at the first line of Execute() method.
4. Note Make sure that the code has not changed since you deployed the timer job; otherwise, the debugger will not match your source code to the deployed assembly.
5. On the Debug menu, click Attach to Process.
6. In the Attach to Process dialog box, click OWSTIMER.EXE, and then click Attach.
7. In the SharePoint Central Administration Web site, click Monitoring, and then click Review job definitions.
8. Click the name of your job, and then click Run Now on the Edit Timer Job page.
9. Verify that the Visual Studio 2010 debugger stops execution on your breakpoint.
10. Happy Debugging.

If the above steps didn't work properly then try the below steps,

• 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.

• Every time the timer job starts, you will get a pop-up window like the one shown in Figure 12. 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.

• 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(.pdb).By adding the following code to the Execute method, you will see your timer jobs running.
• Any time you update your custom timer job class and deploy the assembly to the global assembly cache, you must restart all the timer services in the farm. If you don’t restart the timer service, it will run the old copy of your timer job class. Yes, the timer service caches the assemblies. Restarting the SharePoint timer service is the only way to refresh the assembly cache and force it to use your updated assembly. 
• And follow the same steps again as mentioned above.
• Happy Debugging.