2

I tried the following steps in order to debug a particular custom timer ( installed and activated):

  1. Copied the both .dll and .pdb files in the GAC.
  2. Restarted the timer services.
  3. Attached both w3wp and OWSTimer.exe processes.

But the debugging is still not taking place. The debugger placed is empty circle which displays this message:

The breakpoint will not currently be hit. No symbols have been loaded for this document.

The OWSTimer is shown in a diff username. Does It needs to be run from my account?

Why debugging is not working?

Marek Grzenkowicz
  • 17,024
  • 9
  • 81
  • 111
Thomas Mathew
  • 1,151
  • 6
  • 15
  • 30
  • Why do you ask a new question - you even marked that you got the answer in the [previous one](http://stackoverflow.com/questions/7470154/debudding-a-custom-timer-job-in-sharepoint). – Janis Veinbergs Sep 20 '11 at 11:26
  • 1
    @JanisVeinbergs: the previous question was regarding copying the pdb file in GAC. The answer accepted was for that only. If there is some redundancy, i ll surely delete it. – Thomas Mathew Sep 20 '11 at 12:14
  • 1
    But you didn't actually get a working solution, so maybe the problem wasn't copying the files to gac? I`v never done that. But thats maybe because i copy dll's to gac with WSPBuilder Visual Studio plugin and i actually don't know if it also copies pdb files. – Janis Veinbergs Sep 22 '11 at 08:23
  • by the way i just checked by GAC_MSIL folder and i don't have any pdb files there – Janis Veinbergs Sep 23 '11 at 10:20

5 Answers5

13

Debugging Timer Jobs can be hard... The steps you took sound about right, but you can also do some more:

  1. Timer Jobs run in OWSTimer.exe - you only need to attach to that one
  2. Restart the timer service. For good measure throw in a restart, deploy, restart, iisreset ;-)
  3. Did you do a DEBUG Build or RELEASE build?
  4. Make sure you actually RUN your timer job (as in trigger it)

If your breakpoints are still not hit, do something ugly: use Debugger.Launch() or Debugger.Break() in your code or an assertion which will always fails: System.Diagnostics.Trace.Assert(false);

And then there is MSDN for the rescue.

Dennis G
  • 21,405
  • 19
  • 96
  • 133
  • 1
    Thanks Dennis for the additional points, I found that, for some reason, solution configuration was "Release" mode and not "Debug" mode. I changed back to "Debug" and it worked perfectly. – KhalilG Aug 08 '16 at 12:06
1

Try loading debug symbols manually and see what it says:

To display the Modules window in break mode or in run mod

On the Debug menu, choose Windows, and then click Modules.

By default, the Modules window sorts modules by load order. However, you can choose to sort by any column.

In the Modules window, you can see which modules have debugging symbols loaded. This information appears in the Symbol Status column. If the status says Skipped loading Cannot find or open the PDB file, or Loading disabled by include/exclude setting, you can direct the debugger to download symbols from the Microsoft public symbol servers or to load symbols from a symbol directory on your computer. For more information, see How to: Use a Symbol Server and How to: Specify Symbol Locations and Loading Behavior.

To load symbols manually

In the Modules window, right-click a module for which symbols have not loaded.

Point to Load Symbols From and then click Microsoft Symbol Servers or Symbol Path.

copied from MSDN

You can also try to delete Visual Studio cache just to be sure (from command prompt):

del /Q %LOCALAPPDATA%\Microsoft\WebsiteCache
del /Q %LOCALAPPDATA%\Temp\VWDWebCache
del /Q %LOCALAPPDATA%\Microsoft\Team Foundation\1.0\Cache
Janis Veinbergs
  • 6,907
  • 5
  • 48
  • 78
0

Check to make sure your regional settings are correct - append /_layouts/15/regionalsetng.aspx to the CA URL. If you have the wrong time zone, your job may be scheduled for a time in the past. This has hung me up more than once. If this is the case, set the correct time zone (using the url above), stop and start the timer service (either services tool or open command line - net stop sptimerv4 then net start sptimerv4). Then attach to OWSTIMER and debug.

chopper
  • 6,649
  • 7
  • 36
  • 53
Toe
  • 1
0
  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.
  3. Open the Visual Studio 2010 project that contains your timer job.
  4. Set a breakpoint in the Execute method of your job definition class.
  5. On the Debug menu, click Attach to Process.
  6. In the Attach to Process dialog box, c
  7. If the Attach Security Warning dialog box is displayed, click Attach.
  8. In the SharePoint Central Administration Web site, click Monitoring and then click Review job definitions.
  9. Click the name of your job, and then click Run Now on the Edit Timer Job page.
  10. Verify that the Visual Studio 2010 debugger stops execution on your breakpoint.lick OWSTIMER.EXE, and then click Attach.
KunalSBhosale
  • 1
  • 2
0

Just adding to moontear's post.

I had the same loading debug symbols issue until I added in this code to the first line of my Execute method.

    public override void Execute(Guid contentDbId)
    {
        // If in debug mode, trigger a false assertion to give time 
        // to attach the debugger to the OWSTIMER.EXE process.
        #if (DEBUG)
            System.Diagnostics.Trace.Assert(false);
        #endif
        ...
Ryan
  • 39
  • 1
  • 6