I want to add here, mostly for myself when I come back to review this question, that symbols are not loaded until the assembly is loaded, and the assembly is not loaded until it is needed. If the breakpoint is in a library that is only used in one function in your main assembly, the symbols will not be loaded (and it will show the breakpoint as not being hit) until that function is called.
Start debugging, as soon as you've arrived at a breakpoint or used Debug > Break All, use Debug > Windows > Modules. You'll see a list of all the assemblies that are loaded into the process. Locate the one you want to get debug info for. Right-click it and select Symbol Load Information. You'll get a dialog that lists all the directories where it looked for the .pdb file for the assembly. Verify that list against the actual .pdb location. Make sure it doesn't find an old one.
breakpoint will not be hit no symbols loaded dll
I was integrating a C# application with a static library using VS10 - which I'm new to. I wrote a managed code dll to interface them. I could set breakpoints everywhere but the static lib. I got the message described above - no symbols have been loaded for this document. I tried many of the suggestions above. I could see that the symbols weren't being loaded. I finally noticed a check box Configuration Debug, Enable unmanaged code debugging. That allowed me to set breakpoints in the static lib functions.
Once this code is reached, an exception is triggered and .NET Framework shows a dialog box asking which Visual Studio (i.e. new instance of VS 2008, new instance of VS 2013, etc) you want to use to debug the program. You can choose the existing instance of VS with your project loaded. This will attach the process to your VS session and load all symbols, and now you can debug your project.
If we get the latest from VSTS, all files will be in read only mode. While running project all class library classes get read only and brakepoints turn empty and say "Breakpoint will not currently be hit. No symbols loaded for this document".
I'm working on an add-in for ArcGIS Pro, and I am having some trouble hitting breakpoints in my code when debugging via Visual Studio. I am receiving a warning stating "The breakpoint will not currently be hit. No symbols have been loaded for this document."
I had previous been able to debug the add-in and hit my breakpoints in the code, but I'm not sure what I did. After add a few new controls, I seem to be unable to hit any breakpoints in the code. I've googled around a bit and tried some solutions found in StackOverflow and elsewhere, but I can't seem to resolve this issue. Has this happened to anyone else before? Additionally, when I click one of the controls in my add-in, nothing seems to happen, and then the control will turn gray and become disabled. I haven't seen this behavior before and I'm not sure what I did, as everything was working as expected earlier today.
To verify your installation simply create a new 'ArcGIS Pro Module Add-in' name it 'ButtonTest', once the project has been created right click (in solution explorer) on the project, click 'Add New item', and choose 'ArcGIS Pro Button'. Now open the Button1 class file and set a breakpoint at the open curly for the OnClick method. Click on 'Build Rebuild' then debug your code. Because Pro will only load your add-in when it's needed, you will see the breakpoint Warning you mentioned, however, once you go to the 'add-in' tab in Pro and click on your 'Button1' icon on the tab, your add-in DLL will be loaded and your breakpoint will be triggered.
When I try to define breakpoints in the Assembler and Fortran routines I am greeted with the warning: "The breakpoint will not currently be hit. No symbols have been loaded for this document."
It is probably relevant to mention that the Fortran DLLs are loaded by a VB call to LoadLibrary. The method for Loading and calling the Fortran routines is essentially the same as it was in the 32 bit world, and (though it has been well over a decade since I have worked on this particular software) I'm pretty sure that I used to be able to define breakpoints in the Fortran code.
It has taken a while to get this conversion completed, but I can now report that the "No symbols have been loaded...." problem did disappear after re-creation of the associated projects and solutions.
a) if the new dummy routine isn't present, then this confirms Lorri's suspicion that the wrong DLL is being loaded.b) before doing the first step-into, open the Breakpoints window and click on the Delete All breakpoints (do not delete them individually as this isn't the same, it looks like it should be equivalent, but trust me that it is not). After deleting all break points, set a new break point at the call to the dummy routine. Once you do this, then future break points set in the DLL will be remembered correctly (assuming the correct DLL is the one that gets loaded).
As per Jim's suggestion I have tried to add a "do nothing" routine (called "Tester") to the Assembler DLL and I added a call to this just prior to calling the "official" routine (called "RunUnmanaged"). I deleted all breakpoints, then set a new breakpoint on the call to "Tester". When the breakpoint at Tester was reached, I first added breakpoints to both Tester and RunUnmanaged. Both of these breakpoints indicated they will not currently be hit. I then switched to the disassembly window and attempted to step-into Tester. Maybe noteworthy here is that the "step-into" did not. The action appeared to be identical to step-over. This was repeated when I attempted to step-into RunUnmanaged from the disassembly window.
I need to debug my feature receiver, so I set up few breakpoints, but when I hit F5 in VS2010, they are all missed, and it says that "The breakpoint will not currently be hit. No symbols have been loaded for this document." What should I do to be able to debug my feature receiver?
In the Visual Studio IDE, when I set a breakpoint at a line of code, and start debugging, the breakpoint becomes that hollow maroon circle with a warning that says The breakpoint will not currently be hit. No symbols have been loaded for this document.
I am getting a problem setting debugging breakpoints in Javascript, hovering over the breakpoint I get the tooltip: "The breakpoint will not currently be hit. No symbols have been loaded for this document."
New find: I realized i've been developing Addins since version 10 on the same machine and after re-installing have not always cleaned up legacy ArcGIS data. I found I had an older version of the culprit addin in a previous version of ArcGIS data in C:\Program Files (x86)\ArcGIS. Since ArcGIS will load the legacy addins there was possibly of some sort of a conflict. I removed all legacy arcgis application data (Desktop10.0, Desktop10.1) leaving only Desktop10.2 and the breakpoint came to life. Again I am not 100% if this is the solution but it may be another item on the list to check for.
At first, start debug and in the menu choose the following window Debug >> Windows >> Modules, where you can see what modules were loaded at the debug start up. If you can't see there the yourAddIn.dll then at least you know that it was not loaded by the studio. If you see there and you can't put the breakpoint there then the Studio loaded an old one. To check this, change the assembly's name in the project properties, rebuild the solution, start the debug and you will see the old dll loaded there. I don't know from where does the studio load this old dll.
I have written a DLL in C in Visual Studio, meant to run under LabVIEW using Call Library Function Node. I tried to set breakpoints and debug it using Attach Process. This worked once, and then never again. The breakpoints show as hollow circles annotated with the message, "The breakpoint will not be hit. No symbols have been loaded for this document."
At this point previous instructions will tell me to find my DLL in the Modules list. IT ISN'T THERE. Ever. Even though in my VI's front panel I see output which had to come from a function in the DLL, so it must have loaded.
Also you have to make sure that your LabVIEW VIs link to the latest debug DLL that you created. When you have a different version even if it was just a recompilation without real code change Visual Studio will refuse to let you to source level debugging as it considers your loaded DLL to be something that is not compatible with the current source code. It adds a new signature to the DLL every time it creates it and stores that signature in the pdb file and only lets you do source code debugging if the name and that signature match exactly.
At least unloading all and every VI that contains a Call Library Node that links to your DLL. That also includes VIs that you might have copied into the clipboard. As long as a VI with a Call Library Node is in memory it will hold a handle to the DLL and as long as there is one single handle to a DLL open, Windows will keep the DLL mapped into the process and you can go and replace the physical DLL on disk a million times, it won't replace the DLL already loaded into memory and mapped into a process.
In a previous article we looked at how to debug in Microsoft Dynamics 365 for Finance and Operations. Now that you are debugging, is Visual Studio not stopping on your breakpoints? This could be that your D365 debug symbols are not loading. There are several settings that need to be set correctly to allow D365 debug symbols to load. In this article I will explain how you can troubleshoot this issue.
Follow the instructions in this previous article to add a breakpoint, attach to process, and begin debugging. If all of the above settings are set correctly, the D365 debug symbols should load correctly. You can tell that the symbols have loaded, when you have attached to the process, and the red breakpoint circles are fully filled in. If the symbols have not loaded correctly, the red circles will empty and not filled in. 2ff7e9595c
Commenti