I try to debug a program in Visual Studio 10, but I have a problem with breakpoints. I put *.pdb files corresponding to the *.dll files to the same directory. But while checking modules, I see that each DLL file is signed as Cannot find or open the PDB file.
How can I fix this problem? How can I check where *.pdb files are expected to be located?
The modules (Ctrl-D, M) is a good place to sort out whats going on so you're in the right area.
Right-click the module/dll you expected the pdb to be found for and select Symbol Load Information
It should look in the same directory as your dll to begin with and if it finds the pdb will either load it or tell you that the pdb file doesnt match the dll.
Go to Debug -> Options and Settings -> Debugging -> Symbols, check Microsoft Symbol Servers under Symbol Locations. See attached photo.
I had a similar problem in VS2013 ... something to do with a PDB file and IISEXPRESS. I tried several things and eventually resolved it by doing this:
Tools > Options > Debugging > Symbols and then pressing the "Empty Symbol Cache" button
Upon rerunning my app, it took awhile for Visual Studio to reload all of the symbols but it did eventually do so and the problem was fixed!
In my case, I was debugging a click-once windows app. In the module's Symbol Load Information, it told me the pdb was out of sync with the currently attached image. I had to review the whole list not just the top or bottom item, to get that error text.
That told me to recompile and re-publish what I was attaching to, so the two would match.
That caused the module list to say Symbols loaded for my assembly that I was debugging, and to go on and continue debugging the issue.
Change Project Directory like if you run/debug code in Windows system directory it wont execute with admin permission,
in my case i save my project in C: drive and while i execute code i throw access violation to read input data error then i try it from different location and it work fine
& also you have to load module as well
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?
Visual Studio loads the correct PDB file, but can't find source information for anything in the solution.
Things I've tried:
Clean, reboot, regenerate project (CMake), rebuild
Check the Modules window to ensure the PDB is loaded (it is)
Mess with "Debug Source Files" setting under solution properties
Check the PDB file with symchk (it says the PDB matches the EXE, and that it has full symbol information, i.e. it's not stripped)
Download system lib symbols from Microsoft because why not
Is there some setting that generates a PDB without source information? Or could it be baking bad paths into the PDB? I tried grepping through the PDB and although it appears to have all the symbols, I couldn't find any source file paths.
More info: this is a 64-bit C++ project. Everything is statically linked including the runtime.
The project was missing the /Zi parameter. Apparently this still causes the compiler to generate a PDB file that can be successfully loaded, it just doesn't have any useful symbols in it. No idea why.
More of a specific case answer, with the /ZI option set:
The variable in question here was a HGDIOBJ variable created as a return from SelectObject. Its Type in the Watch window was void *.
The action was to "Break When Value Changes", and after continuation the VS windowed code graphic bounced back to the beginning of the main WndPRoc with:
When 0xbd1676ecb8 (Original Expression: hMyObj) changes (8
bytes) in process 'MyProg.exe'
after which the "Source Not Available" dialog was shown.
So, what to do? If there were issues with the VS2019 installation on this machine, they applied only to this particular variable type, thus the decision was consequently not to use "Break When Value Changes" for that type.
At the bottom bar of visual studio, click Application Output and resolve the error from the exception which was produced.
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.
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.
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"