I ported an application from VC6 to VS 2008. I rebuilt the application in release build. The Pdb file is available in the folder where exe is located. But when I loaded the application and put break point I am getting the following message
"The breakpoint will not currently be hit.No symbols have been loaded for this document"
What would be the cause of the issue?
The debugger could not find either the application or the PDBs.
When you start the program, exactly which binaries are loaded are shown in the Output window. Make sure the right files are being loaded. When everything loads properly, the output looks something like this:
'hacks_vs10.exe': Loaded
'C:\Users\john\Documents\Visual Studio
2010\Projects\hacks_vs10\x64\Debug\hacks_vs10.exe',
Symbols loaded.
When the PDB is not found, instead of saying "Symbols loaded" it says:
Cannot find or open the PDB file
Make sure that you are first running the correct version of your application (check the running path), and then make sure that the PDB is in that directory. You can change where the PDB is generated to by tweaking "Project>Properties...>Linker>Generate Program Database File"
The debugger could not find code associated with the source location you put the breakpoint at.
There can be a number of reasons for this. The one I've most often found was a section of code that was truly not compiled in. (either because of preprocessor conditionals or dead-code removal).
I imagine there can be other reasons too (e.g. inlining, though in theory, the compiler could generate the proper mapping for all the inlines. I don't know what VS2008 does here).
Are you sure you're putting the breakpoint in a code path that is supposed to be executed ?
The PDB file you mention is probably not related to the release build,
Debug information is normally absent in the release build (though you can enable it if you have to but should anticipate surprising effects due to compiler optimizations).
Therefore, you can only set breakpoints on known DLL entry points (possible via the Module List view - it has been a while since I used Visual Studio intensively) or directly on assembly instructions.
Note that you could perhaps compile part of your application with debug symbols.
I have just solved a similar problem
I re-referenced all my DLL's
went to (Tools->Options, "Projects and Solutions", "Build and Run") and set "On Run when projects are out of date" to 'Prompt to build'
I'm not sure which of these fixed the problem, but it did!
Related
I'm trying to profile a Win32 native application which also makes use of some external DLL's which are same Win32 native build.
When I stop data collection at some point, the profiler starts generating an overview how much process time and data are collected where - but whatever it is, it always shows me "External code" in this tree.
To clarify my problem: this happens for all positions in my application, means where sources are available and which are built with debug symbols!
Any ideas what could cause this? Thanks!
if you want show source code at debug or profiler mode, you must got pdb file for bins(include exe and dlls).
for "some external DLL's", may you can't get a match pdb.
for you win32 exe, you must generate pdb file for debug, you can google it.
I have a c++ application that uses the g3log library to provide stack trace information when a crash happens. My release configuration also builds full pdb file so that this is possible. My app.exe stores the full path to the pdb file, that is I am not using /PDBALTPATH:%_PDB%.
When I am running the .exe from any folder path, so long as the .pdb has not been moved, then if I force a crash, I get a meaningfull stack trace. Now if I move the .pdb file to be in the same directory with my .exe it is not loaded anymore. My guess is that is does not match the path in the .exe. I thought that a .pdb file with the same name as the .exe would be loaded, I guess I was wrong.
I have tested by specifying /PDBALTPATH:%_PDB% such that there is no path information but then the .pdb file is again never loaded.
For both cases if I attach a debugger all is good in the debugger but not in my stack trace.
Is there a way to get the "automatic loading" of the .pdb (not sure how to call it) from when it matches the full path to happen when the .pdb is in the same directory. That way I can get a meaningful call stack when needed.
In general, your use case seems pretty weird. Because unexpected exception usually means an undefined state, and there is no sense to continue. So you need probably to save a dump and investigate it later with your PDB files.
I'm not sure about the inner mechanics which gets the stack trace information in your dev environment. But usually, a debugger is looking for PDB files and trying to load it from different places. And when you place a PDB file with an EXE file, you make it possible to be found by a debugger.
For example, my build server saves PDB files while building to my local symbol server. And when I debug a crash dump with my debugger, it gets desired symbols correctly.
I have never tried to do things you are trying to do. In fact, it looks like debug build in production, which is not a good practice. So, I would consider an approach I described above.
You can set this path;
set _NT_SYMBOL_PATH=C:\MySymbols, where your pdb files are there.
Thats the simple way, if you cant set this path, then follow below procedure.
You mentioned:
When I am running the .exe from any folder path, so long as the .pdb has not been moved, then if I force a crash, I get a meaningfull stack trace. <<
So, always make sure your app runs from the directory where the .exe+.pdb files are there.
You can do that with GetModuleFileName+SetCurrentDirectory.
That means, your working directory is different.
I would suggest is, in you application, get "GetModuleFileName".
Then change the working directory to exe path using: SetCurrentDirectory.
It seems that #prasad-mk is half way correct. Setting the _NT_SYMBOL_PATH somehow forced my .pdb symbol to be loaded as in the case where the path matches.
Another option that I found is by using this utility
http://bytepointer.com/tools/index.htm#peupdate to update the path to wharever the location of my pdb is.
I'm currently working on a tool that allows me to change C++-code on the fly. Changed files are compiled in the background, loaded from the .obj, relocated & linked, and patched into the running process.
This works fine so far.
However, I have been unable to load symbols for the new functions so that they are visible by the debugger. I have tried creating a virtual module using SymLoadModuleEx and adding symbols via SymAddSymbol, but that didn't work.
Ultimately, I would like to be able to add symbols and line information for the new functions. I could do that from either a .pdb file or the COFF info stored in the .obj (I have both), but I seem to be missing the crucial part that informs the debugger.
Is there a function for this that I simply missed? Or an undocumented code for RaiseException that is understood by the debugger (similar to naming a thread)?
I use Visual Studio, but any help in getting this to work in either the VS debugger or WinDBG is greatly appreciated.
I have a project built in VS 6.0, now I have to debug it remotely in VS 2010.
I am able to browse the source correctly, create a breakpoint and trace through lines, inspect simple types, but not complex data types. It looks as it didn't load them.
I had been able previously to debug with WinDbg, there I can read complex types, but have another (not really understand what) problem with inspection...
I have also tried to debug in VS 2013, where I can't even open PDB, it says that PDB can't match executable.
I must say that PDB is exact match of an EXE recently made, but in VS 6.0.
So I'm asking if someone have experience debugging with PDB, am I missing something? Is it possible that I'm using an old PDB which don't have type information?
Update:
When I open pdb file in Notepad, it looks that the symbols that debugger cannot find is really missing from pdb. So it happen that, from the same source file, some global variable names appear in pdb, and some not. Plus the debugger says that it cannot find symbol for complex type, even if it exists in pdb. The source code is not written in respect to new C++ standard, so it cannot be compiled in VS 2013, maybe that have effect.
The modules window (Ctrl-D, M) is a good place to understand whats going on.
Right-click the module/dll that you expect its 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 doesn't match the dll.
I hope it will help you solve your issue.
I have built a particular dll with debug information (compiler option /Zi and linker option /DEBUG). Through an interrupt statement in the main program, I launched the Visual Studio for debugging. In the list of modules shown as seen from Debug->Windows menu, I could see that the symbols have been loaded for the dll interested in. However when I open a C++ file from that dll and try to set a breakpoint, it says debug symbols are not available for the document. There is no question that this C++ file was compiled into that dll, and that it is the same source used to build the dll (I only did it). Why does this happen? Please help, before I shoot myself.
I don't have a definitive answer, only a few suggestions.
Sometimes mdm.exe (Machine Debug Manager) stops to work properly. Terminating the process and re-starting Visual Studio helps. If the problem persists between reboots however that probably isn't the cause.
Source-file-times (last modified) that are in the future can cause all kind of weird problems. To check file times, you can do a search for nothing (Windows XP) or "*" (Windows 7). That will list all files in the selected folder. Then sort the result by date to see the max/min file time. I have no idea where the incorrect file-times come from - I just know that it happens from time to time. Might be Visual Studio itself, might be some other tool I'm using.
You could try to start the application that uses your DLL from Visual Studio, with your DLL project already open. To do that, open the "Configuration Properties", select the "Debugging" page, and enter the .exe that should be started (+ arguments if you need any). Then start the debug session as you would for a .exe project.
A cure for many problems with Visual Studio is to "clean" the project manually, and do a full re-compile. Delete all files that are generated during a build process or that store solution or project "options". i.e. all .suo .ncb .user files plus everything in the "intermediate" and "output" folders. If you're using source control, just retrieve the whole project from your source control system into a clean directory, and re-build from scratch. (Getting everything "fresh" from source control also takes care of any potential file-time problems - at least with source control systems that don't preserve file-times)
Another possible reason would be, that VS loads the wrong .pdb file. A .pdb file with a matching name could be found in a symbol server/symbol directory configured for VS (or system wide through the _NT_SYMBOL_PATH variable), or in the VS symbol cache directory. How a .pdb file with a matching name came to be in such a place is a different story, but one can easily check if the wrong .pdb file is loaded: delete the .pdb file generated by the build, and start a debug session. If VS traces "symbols loaded" for the .exe/.dll in question, it must have found a .pdb file in some other location.
Sometimes VS seems to mess up breakpoint locations in some way. I don't exactly know when or how this happens, but one of the symptoms is, that if one deletes some breakpoints, they magically reappear when starting the next debug-session. I found that setting a new breakpoint, then deleting all break points by Debug/Delete All Breakpoints, and the re-setting the required ones helps.
1) Are you not able to hit the breakpoint at all ? Generally, it gets resolved once the code in the module or stack frame needs to be hit.
2) Check if your pdb is not source information stripped
Do a Build->Clean Solution, close visual studio and then restart it and do a fresh build. This happened to me once before, and that seemed to fix it, just some outdated pdb information, I suppose.
In my case, I had renamed the C++ project. The compiler was outputting newName.lib while my other projects were still referencing oldName.lib which of course would not be removed by a Build->Clean.
I found this out by following the advice to manually clean the build directory. The subsequent linker unresolved external reference gave away the situation.