Sign in
Microsoft.com
 
Microsoft
 
 
 

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

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello,

    I totally have no idea about this. I was trying to debug plugin. It never stop at the breakpoints. I can see this yellow mark "

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

    ".

    I can tell all my plugin codes have been executed. plugin registration done successfully, copy all PDB under crm server\bin\assembly, depended DLL put under GAC.

    I don't know what else I need to do for setting. Need your help!

    Thanks in advance!

    Thursday, July 25, 2013 4:44 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    I think this because your code could not compile - maybe due to a syntax error or something prevented it from compiling and therefore breakpoint can't be set.

    Robert

    Thursday, July 25, 2013 6:11 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    It's already being built and being excuted in CRM successfully. 
    Thursday, July 25, 2013 7:24 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    there is a list of  possibilities.

    some things that worked for me:

    refresh IIS

    remove and reinstall the plugin

    for workflows, sometimes you need to delete the workflow and reinstall

    if remote debugging try to debug as admin and lounch remote debugger as admin

    restart any service related, like crmasync

    I Hope I could help. If I have answered please mark as 'Answer'. If was just helpful, please vote. Thanks and happy coding!

    Thursday, July 25, 2013 8:14 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I've already tried all these steps before. still failed.
    Thursday, July 25, 2013 9:19 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I had a similar problem.

    Attaching the debugger to w3wp.exe made it work.

    I had to attach to this process as my crm deployment was installed on a different server to my development server.


    • Edited by madbrendon Thursday, July 25, 2013 9:49 PM Making answer more clear
    Thursday, July 25, 2013 9:48 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    I've been having a similar problem with a very old virtual machine and managed to sort it by going to my Visual studio tool >options > debugging and uncheck "enable just my code (managed only)". it didn't work initially but after restart the VM it is now working fine.

    is your plugin sync or async.

    I guess you know the services to attach according your plugin  deployment

    I Hope I could help. If I have answered please mark as 'Answer'. If was just helpful, please vote. Thanks and happy coding!

    Thursday, July 25, 2013 10:58 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I figured out another possible scenario. I've been using linq with my crm and the classes are in a different DLL. because it  became different , it didn't break the compilation but I had a dll with a different token number on my solution. everything was fine but after deploying the debugger was not being able to step in. after generate a new class and make sure all the dll references were correct , I just deployed it again, put the pdb on the  crm assembly folder, attached to the w3w process and it worked just as new. I believe that before the machine restart this ddl confusion got stuck on the dot net cache folder and because the VM was not properly shut down that could had added to the problem

    I Hope I could help. If I have answered please mark as 'Answer'. If was just helpful, please vote. Thanks and happy coding!

    Thursday, July 25, 2013 11:27 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I created another very simple plugin application for testing. It doesn't work either. I think it's nothing related to code. Like I said I know it's being executed in CRM, but can't hit breakpoints for debugging. 
    Friday, July 26, 2013 2:54 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    In Visual Studio, when debugging, go to the Debug, Windows, Modules window - this will list all assemblies in the process, including your plugin assembly, and may give more information about why the symbols can't be loaded. You can also specify an alternate location from which to load the symbols.

    You say you have a dependent assembly, are you trying to debug this assembly, or the plugin assembly ?

    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Friday, July 26, 2013 4:42 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    Yes. I did this too. After attach to process, from module window, I don't find my plugin DLL there. after loading CRM form(either run create or update), I can see my plugin DLL, but the symbol status is "Cannot find or open the PDB file". Then I try to 'load symbols from symbol path'. locate my plugin PDB file, but it says 'A matching symbol file was not found in this folder'. I know you'll say 'That's because the DLL I'm running doesn't match with the one on the server', but I've already done all I can(I delete all bins and obj, rebuild plugin, copy it to server\bin, update via registration tool, restart Asyn process service, restart IIS). I think they should match, but it still comes back with no luck.
    Friday, July 26, 2013 8:38 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    The Modules window will also show where your assembly is loaded from - is this where you expect ?

    Are you using Remote Debugging ? If so, although Visual Studio will browse to a local directory for the symbol path, the path will actually be applied on the remote server

    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Monday, July 29, 2013 6:01 AM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks BrunoLucas, this finally fixed a problem where my module no longer appeared in the Debugger's Modules-window :) - and it is the correct version, from my development area. How on earth did you find this out?

    Unfortunately though, my breakpoints are still not active.  So a good step forward but I'm not quite there yet.

    [BTW I also needed to:

    - update my symbols paths, as I am using a new working area (in Debug > Options > Symbols).

    - in the "Attach to Process"-dialog form, select: Managed (V4.0) code, Native Code, T-SQL code

    - yes, of course, attach the debugger to w3wp.exe

    - perform an action (Save in my case) to cause the plugin to load. ]

    UPDATE: finally got breakpoints working for me again by searching my entire C:-drive for copies of my plugin's .dll & .pdb file - I found about 18 copies of each!!!

    I deleted them all and rebuilt my development node (solution) - this produced  6 copies!  I re-started my virtual machine (to reset VS, IIS, etc.)

    and, to my surprise & delight, my breakpoints started working again! :)


    • Edited by Zeek2 Tuesday, March 11, 2014 2:35 PM
    Tuesday, March 11, 2014 10:03 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Howexg9,

    Please reset you IIS and then make a try again by following the step of debugging.

    Tuesday, March 11, 2014 2:24 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    It means there is noone on this earth who can solve this problem?
    Thursday, November 6, 2014 2:20 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    It shouldn't be that hard. The key things you need to know are:

    • You can't debug assemblies in the sandbox
    • If the plugin is run synchronously, attach to the w3wp.exe process. If it's asynchronous, attach to CrmAsyncService.exe. You may have more than one instance of either
    • Use the Debug\Modules window to see f your assembly is loaded, and where from.
    • Ensure the version of the .pdb file matches that of the .dll - i.e. they were compiled at the same time
    • There are many places where the .pdb files may end up - it's a good idea to delete all but one
    • If using remote debugging, note my comment above about local and remote paths

    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Thursday, November 6, 2014 7:09 PM
    Moderator