I have a Windows service and I have written Debugger.Attach() in the Onstart method of the service.
When I start the service I get a popup which asks to select the debugger instance.
When I select and press ok, the visual studio comes into focus but shows me "No symbols have been loaded" message.
I followed two steps
1.from here http://geekswithblogs.net/dbutscher/archive/2007/06/26/113472.aspx
While debugging in Visual Studio, click on Debug > Windows > Modules. The IDE will dock a Modules window, showing all the modules that have been loaded for your project.
Look for your project's DLL, and check the Symbol Status for it.
If it says Symbols Loaded, then you're golden. If it says something like Cannot find or open the PDB file, right-click on your module, select Load Symbols, and browse to the path of your PDB.
2 goto Debug-> options and settings ->
under the debugging node -> general ...uncheck "just my code" checkbox
and it worked...
I most commonly see this issue when the build of my project that is running doesn't exactly match the build currently loaded in VS. For example, I build my VS project, then I make some (any) change to a file in the project and save without rebuilding. Then if I run the executable/service/DLL the previously built version will run and since it doesn't match the version I have in VS (thanks to my code change), it won't properly attach.
The specific issue in this case is that the VS debugging PDB file does not match the source code making debugging impossible.
This may not be your issue, but I have seen the "no symbols..." error countless times and it is usually a case of the code being executed not matching the code in VS.
Related
I am trying to step into a form.Show() method (to figure out why calling Show on one mdi child triggers a resize on all other mdi siblings), however no matter what I do I can't get visual studio to step into the show method.
Yes I disabled 'just my code'
Yes I enabled 'framework source stepping'
Yes I enabled source server support (and also enabled all sub-options for good measure)
Yes I disabled 'require source to match exactly'
Yes I disabled 'step over properties and operators'
Yes I enabled 'microsoft source servers'
When I open the modules window, System.Windows.Forms shows 'Symbols Loaded'.
When I ctrl+click on the Form.Show() method, it takes me to the code.
When I enter a breakpoint, the breakpoint is disabled and it says 'No Symbols loaded'
I have tried this with both VS2019 and VS2022 and both exhibit the same behavior.
So it looks like some parts of VS know where to find the symbols and other parts of VS (namely the debugger) can't find the symbols. Is there any way to get all of Visual Studio on the same page with regards to where to find the symbols?
Also I have tried this:
https://stackoverflow.com/a/10908685/229250
It didn't help.
The callstack (which I would assume shares the same context as the debugger) also has no idea where to find the symbols. When you double click on any part of the stack that has to do with dotNet framework method calls, I get a screen that says 'Source information is missing from the debug information for this module' with NO option to select a source file (I downloaded the source expecting to be able to do this but nope).
What's even more strange is that in VS2022, when you run the debugger and you open 'Solution Explorer' there is a section that appears at the top called 'External Sources', under that there is a node 'Modules without sources'. Under that node I have 2 copies of System.Windows.Forms.dll. When you right click on one of them and select "Symbol Load Information" it says symbols were loaded and shows the path to the local symbol server download cache. When you do the same for the other copy of the dll, it shows "Binary was not built with debug information." and ALL of the framework dlls have the same problem and I can't step into any framework code or set any breakpoints.
#Hans Passant
Here is the symbol load info you requested (from the modules window):
C:\projects\MyProject\bin\Debug\System.Windows.Forms.pdb: Cannot find or open the PDB file.
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.pdb: Cannot find or open the PDB file.
C:\WINDOWS\System.Windows.Forms.pdb: Cannot find or open the PDB file.
C:\WINDOWS\symbols\dll\System.Windows.Forms.pdb: Cannot find or open the PDB file.
C:\WINDOWS\dll\System.Windows.Forms.pdb: Cannot find or open the PDB file.
C:\Users\myUserId\AppData\Local\Temp\1\SymbolCache\System.Windows.Forms.pdb\098daa586c564b1ab756109f800f14ff1\System.Windows.Forms.pdb: Symbols loaded.
As I mentioned above, if you try to get the load info from other places, it says symbols aren't loaded.
EDIT 1
So it seems there is a problem in visual studio, even though I have all my projects set to Framework v4.6, the Modules window shows that the version of Winforms being loaded is 4.8.3752.0 built by: NET48REL1
Is there any way to get VS2022 to load the same version of Winforms that the project is set to?
.NET 4, console application. The project is set to 'Debug' mode. The breakpoint being set is in the primary/startup project. I have right-clicked -> Clean, and right-clicked -> rebuild, both on the Solution and project levels.
Following the instructions in this SO question, I have confirmed that my "Build and Run" options are set to 'prompt' for both 'When projects are out of date' and 'when build or deployment errors occur', and I am NOT getting a prompt when I F5 to build/run.
Also, the 'save all changes' under 'before building' is also selected (plus I manually saved them myself).
I monitored the output window of the application, see this line:
'MyApplication.exe': (Managed (v4.0.30319)): Loaded 'C:\exepath' Symbols Loaded.
I restarted the VS2010 instance. I restarted all open VS2010 instances (of other projects). I've even gone through a reboot.
However, the breakpoint I am setting in the startup project is a hollow-red circle, with the notice that 'This breakpoint will not currently be hit, The source code is different from the original', and, in fact, is never hit.
So, this is really 2 questions:
1) How do I fix this problem so I can properly breakpoint
2) When I see this, does that mean my code is executing from an older build?
I've had this problem once myself but that was on a vsto addin. In that case there were left over intermediate files under the users/appdata directories that were actually loaded instead of my app.
There is this blog article that has a whole load of possible reasons for this error and then a whole bunch more in the comments from other users
This can also happen if you have a solution with multiple projects, and have the wrong project selected as your startup project in VS2010 and VS2012.
Now, obviously, I wouldn't expect debugging to work if I have the wrong startup project selected -- the debugger is attaching itself to the wrong process!
But this error message (in my case) was terribly misleading. It made me think something else was wrong. I tried a bunch of solutions in this thread (nuking various /bin and output directories) when really it was something very simple (wrong startup process).
If you are using vb, check that you are building the project for the active solution configuration (Build, Configuration Manager..., Column under Build is checked. Also check the project properties, Compile tab, Advanced Compile Options, and Generate debug info is set to Full. Sorry I can't tell you where this may be in C#.
The only other time I've seen this is when two projects in the solution are referencing the same dll but they are referencing from different sources. One from a project reference and another from a file reference for example. If the "copy local" option is true, there would be the potential of overwriting the dll with an older version of the same dll.
My solution might help people who have signed the assembly.
After lot of head scratching for the past two days, I was able to resolve the same issue by doing the following simple steps:
Go to your Visual Studio project properties.
Go to the "Signing" tab.
Uncheck "Delay sign only" option if it is checked.
Now run your project and it should work.For me it did work.
In my case was this same problem (“The breakpoint will not currently be hit. The source code is different from the original version.”) caused by fact, that I tried add breakpoint to declaration:
DateTime dt;
bool b = DateTime.TryParse(null, out dt);
(first line of code)
So I assume that message is "universal" and may have many different causes.
This can happen if your system clock was changed since the last compile. Your PDB file will be different date than the one your are trying to debug. Delete the PDB files in the project and recompile.
I experienced the problem when Project > Properties > Web did not have "Enable Edit and Continue" selected. After enabling this feature the issue was corrected.
It is important to note that under Tools > Options > Debugging > Edit and Continue "Enable Edit and Continue" was selected, but it was not enabled for this project.
Just go to Tools / Import and Export Settings
Choose reset all settings then click Next
No, just resetl settings, ovewriting my current settings then click next
Choose your current language, por example C#. then click Finish
If you have multiple solutions open, try simply closing all Visual Studio instances and restarting only the instance you need.
In my experience this has happened when two branches of nearly identical code are open in different instances.
doing a "clean solution" from VS Build Menu might help you.
I had to go over all those steps to fix the issue on my computer.
Make sure that debug = "true" on your web.config
Clean and rebuild all projects
Delete every file inside the bin folder of all projects
Close and open Visual Studio, rebuild, and run the project again.
Go to your solution folder -> obj -> Debug - > delete the .dll file and build the solution again.
I'm developing a .NET 4.0 app in VS 2010.
I'm trying to use dump files for the first time, but when loading the minidump into VS, I can't debug it, since VS doesn't find the source files.
Here's what I did:
In Options -> Debugging -> Symbols I added my app's build dir, which contains the pdbs.
Ran the app in the VS debugger. Selected Debug -> Break All.
Selected Debug -> Save dump as
Went to the dump file in windows explorer and opened it. This opened a new instance of VS.
I clicked "Debug with mixed". This opened a new tab that said "There is no source code available for the current location.
I tried to figure out why VS wasn't loading my pdbs:
Opened Debug -> Windows -> Modules
The Symbol Status column for MyApp.exe said "Symbols loaded".
For MyApp.vshost.exe it said "Cannot find or locate the PDB file".
Rightclicked on MyApp.exe, selected "Symbol load info". It said "MyApp.pdb: Symbols loaded."
Did the same for MyApp.vshost.exe. It said vshost32.pdb: Cannot find or open the PDB file.. (note how it's looking for a file named vshost32.pdb rather than MyApp.vshost.pdb, for some reason)
So, any ideas?
Solved the problem. VS was looking at the bottom-most method in the call-stack, which was a system method somewhere in ntdll.dll. So naturally there was no source for it. I had to click on my own method in the Call Stack window to navigate to my own code, for which source was available.
My Visual Studio 2010 debugger sometimes has a very strange behaviour...
Sometimes it doesn't stop at breakpoints, but when it stops, and I want to step into a method, the debugger just steps over it. Also the breakpoints in those over-stepped methods are ignored.
When this strange behaviour occurs, it also does not break on exceptions but simply ignores them.
I've tried to rebuild my project, reset the Visual Studio settings and disabled debugger settings like "Break only in my code", but nothing has worked.
How do I solve this problem?
Here are a couple of reasons and workarounds for why Visual Studio will avoid stepping into a particular method.
Just My Code is enabled. In certain circumstances the "Just My Code" setting will prevent you from stepping into a method / property. To avoid this you can disable "Just My Code" in the debugger options page (Tools -> Options -> Debugger -> Uncheck "Just My Code")
Symbols are not loaded for the target method. If the target method is a part of another DLL it's possible that symbols are not loaded for that DLL and hence Visual Studio will not be able to step into it by default. To force the symbols to load, open up the Modules view (Debugger -> Windows -> Modules), navigate to the DLL containing the method, right click and load symbols.
The method is explicitly marked with a debugger attribute such as DebuggerNonUserCode which causes the debugger to step over the method.
The method is actually a property or operator and you have "Step Over Properties and Operators" setting enabled (this is the default). This can be disabled via the debugger options dialog.
In my case it was "Step Over Properties and Operators" in Tools -> Options -> Debugger. Just had to uncheck that and after that everything was fine, I could step into.
Another source of confusion is iterator methods that use the yield return operator because they are rewritten by the C# compiler in such a way that stepping into them (F11) is kind of a "no-op".
You must wait for the iteration to occur to break into the method's code.
I've found the solution of the problem and it is really simple:
In my solution's build configuration, the "Build" check-box of the project where the methods are, that get over-stepped, was not checked. I checked it, and now everything works.
The most important thing to check is whether when trying to put a new breakpoint inside the method it refuses to step into, if the breakpoint is filled red liked the others, or half filled or has a special "look". If it does, hover over the breakpoint you created to find out why it isn't working.
If the breakpoint looks normal but still you can't seem to step into the method, try clearing the shadow copy cache: http://weblogs.asp.net/mreynolds/archive/2003/08/11/23576.aspx
Another thing to try is to make sure that you are indeed using the DLL you've just rebuilt by adding a MessageBox.Show (or something similar) to the method you can't seem to stop at, and make sure you get the box.
I struggled with this for a while. None of the answers given worked for me. I finally got it to work by doing the following:
Make sure the project is in debug mode (all projects)
From Windows go to a Command prompt and be sure to run as administrator
Navigate to c:\windows\syswow64\ (or folder where gacUtil.exe is located)
Run the following command (substitute path below to where your debug output version of the DLL is located.
gacutil /i "C:\Users\John\Documents\Visual Studio 2008\Projects\Project1\Project1\bin\Debug\MyAppDLL.dll"
You should get "Assembly successfully added to the cache"
Now run your project and you should be able to step into the DLL code.
WAG here, but I'd say you've referenced another project in your solution by BROWSING to a dll (project/bin/debug/mydll.dll) rather than by adding a "Project Reference." If you have multiple projects in your solution, remove ALL references to each project. Then, in the Add Reference dialog, hit the "add project reference" tab and select the project you wish to reference.
Project references are always updated on a new build. But if you, say, browse to bin/release and add a reference to a dll in that directory, when you switch to debug mode and add code and try to debug it, the old release version of the dll is loaded into the appdomain and VS won't be able to hit any breakpoints (you'll notice the breakpoints are empty circles and the tooltip will say something about the code not being loaded).
I have just found another reason for the problem, and a fix. I am creating a Windows Forms application using C++ in Visual Studio 2010. I am using the FreeType library and some code which depends on it and for various reasons this code has to be compiled with 'No Common Language Runtime Support' selected (Properties -> Configuration Properties -> General). I was not able to get breakpoints to be hit in this non-CLR code.
The fix is that the main app must be compiled with 'Common Language Runtime Support (/clr)', NOT 'Pure MSIL Common Language Runtime Support) (/clr:pure)'. That immediately solved the problem. I can now debug into, and hit breakpoints in, the non-CLR code, including the FreeType C code.
I have experienced the same recently. Not sure what I did exactly though. Try to physically clean up your solution, i.e. delete all bin directories from all projects of the solution. That usually helps to solve a lot of problems.
Try disabling "Require source file to be exactly matched" option in tools->options->debugging->general.
My solution was to create a new project and load all my .vb files into the new project. Solved all of my issues.
My problem was simple. I have multiple projects in the solution and I just need to set the project I am working with as Set As Startup Project.
I am currently bug hunting and need to debug into a specific dll in the release configuration in Visual Studio 2005.
At some point I closed the solution, did some other stuff and reloaded it. From that point on my breakpoint doesn't get hit and I get the infamous "No symbols have been loaded..." message. So I opened the modules window and the dll that I want to debug doesn't appear in the list anymore, therefore I cannot load symbols manually. The application behaves normal so I am absolutely sure that the dll MUST have been loaded to execute certain functions. Sure enough, if I rename the dll and start up the application it doesn't work anymore, so it also must be the right dll.
I tried setting the dll project as startup project and the command to execute to the application's exe and starting the application from outside visual studio and then attaching to the process, all to no avail.
Question is, why is the dll not appearing in the list of loaded modules although it must have been loaded? I cannot think of any other changes that I've done, that could cause this, am I missing something? (Maybe something really obvious?)
Any help appreciated!
Use process explorer to check if the dll is loaded or not.
When you attach the process make sure that you are enabling both 'Native' and 'Managed' code type (in the code type selection option).
See also this question: Visual Studio is not loading modules when attaching to process
I encountered a similar issue after transferring a project from one computer to another. I will simply explain what I discovered and how I fixed it, and you can determine if it fits your problem and solution.
The work computer I wrote an application on contained a .dll file which my program was referencing. After moving the application to my home computer, the application could no longer locate the .dll file it was previously referencing because the file was no longer there.
The application compiled and ran even without the referenced resource (.dll file) because the previously compiled assembly (debug folder) contained its own copy of the .dll file and other resources. Put simply, it is the old assembly build that is running and not the current application you're working on. This is also why this error tends to suspend the designer window and throw an error after the app is done running.
I would take a look at the following:
a) Under Solution Explorer, go into the References folder and right click the missing reference node and select properties. In the properties box, observe the Path of the resource being referenced. Is the resource still located at this path?
b) Check the debug folder for a copy of the resource you're looking for. If the resource is there, make a copy and save it to your desktop. If it's not there, get the file from the original source.
c) Under Solution Explorer, right click 'Properties' and 'open'. From the menu that appears select 'Resources' from the left and at the top of the new window that appears you you should see 'Add Resource' with a small drop down arrow. Click the arrow and select 'Add existing file' and then browse to the file. If you don't see it you may have to change the file being browsed from the small drop down above the 'open' and 'Cancel' buttons. After the file is located it should create a new folder in the solution explorer called 'resources.' Now the file is a permanent part of your application and not merely a reference to it.
I had the same issue today with Visual Studio 2008. I was using a simple tester to test a new method in an assembly. So added a reference to my assembly I wrote the code to load the assembly and call the new method, build, everything OK. But during execution the debugger would throw an exception saying that new new method did not exist, and the modules window was empty.
Turns out the assembly I was modifying was in the GAC, and was using instead of the new one in my build directory.
I had the same issue with visual studio 2017 Pro and searched for a week but no luck then i installed VS2019 Pro and test with same project but the break point wasn't working at all and the project's DLL was missing from the modules list.
I was running multiple projects under one solution and i suddenly observed that if select project1 as "Startup Project" the DLL of that project is loaded only in the module list. So as i was testing an API and I switched API project as Startup Project and observed now the API DLL files are loaded into the modules list.
Right Click on your required project that you want to include it's DLL files in the module list and set it as "Startup Project"