I made C++ application to use with WinDbg, and intentionally add access violation run-time error.
Application was compiled as release build, and then I copied exe from release folder to desktop. Still when I use WinDbg, and application crashes, it open my source code file showing error line highlighted.
I am not able to understand, how WinDbg understand my source code file path.
Also, when I get crash dump from client, it may be possible, I do not have source code available with me. So I want to simulate real world scenario.
Regards
The way I understand it, Visual Studio compiler generates a .pdb file for any executable it creates (when /DEBUG flag is set). This PDB (Program Database) file contains information (including paths to source files) required for the debugger to match address in a binary module to source code. And it seems that a path to .pdb is hard-coded into the binary. So when you move a binary itself, debugger can still find pdb, from which it finds the sources.
All paths are probably absolute and will only work on the PC which compiled the binary.
.pdb has source file full path name information. open a .pdb file you will see lines like this:f:\dd\vctools\crt\crtw32\stdcpp\locale0.cpp
Related
I am trying to debug a .exe file with a .pdb. The project is using SCons, and here is the part where it compiles in sconstruct:
env.Append( CCFLAGS=["/EHsc"])
env.Append( CCFLAGS=["/DEBUG", "/Zi", "/Fdgame.pdb"])
env.Program('game', ['game.cpp', Glob('feather/*.cpp')], LIBS=['SDL2', 'SDL2_image', 'SDL2_ttf', 'SDL2_mixer', 'SDL2main'], LIBPATH='lib/Windows/lib')
So I'm adding the flags that are correct (I think) to generate the .pdb. The pdb shows up in my project directory, in the same location where the .exe is. After looking at its contents, I'm pretty sure that it has the correct information to work (at least, it is not empty). I am setting game.exe as the startup item, then running it from VS 2022. However, after running the .exe, Visual Studio claims that the "Binary was not built with debug information."
Modules tab showing this message under "Symbol Status."
According this page on the Microsoft VS documentation, it says:
The debugger searches for symbol files in the following locations:
The project folder.
The location that is specified inside the DLL or the executable (.exe) file. By default, if you have built a DLL or an .exe file on
your computer, the linker places the full path and filename of the
associated .pdb file in the DLL or .exe file. The debugger checks to
see if the symbol file exists in that location.
The same folder as the DLL or .exe file.
My .pdb should fulfill conditions 1 and 3, so I'm confused as to why it can't be found (if that's the issue). The docs do mention that this applies when you build a project, but I've seen other video tutorials online where they just attach .pdbs to running processes and it still works. Is there anything I'm missing?
Try changing to
env.Append( CCFLAGS=["/EHsc"])
env.Append( CCFLAGS=["/DEBUG", "/Zi"])
env.Program('game',
['game.cpp', Glob('feather/*.cpp')],
LIBS=['SDL2', 'SDL2_image', 'SDL2_ttf', 'SDL2_mixer', 'SDL2main'],
LIBPATH='lib/Windows/lib', PDB="game.pdb")
If that's still not in the correct location then change to
PDB="${TARGET.dir}/game.pdb"
See the manpage for info on the PDB environment variable:
https://scons.org/doc/production/HTML/scons-man.html#cv-PDB
When debugging a crashdump for using Visual Studio, I notice that it prints a message about looking in the pdb to see if the source file it is looking for is there:
Searching for documents embedded in the symbol file.
How can I get MSBuild/msvc to include source files when generating PDBs?
Our current solution is to embed a script in the source file that downloads the relevant source from a given URL. However, that is giving us trouble because many machines we debug on don't have access to the source URLs and also the URLs for old builds may become invalid if a project moves.
I'm trying to debug an exe that calls a dll, in Visual Studio. I made sure I had the corresponding pdb in the same path as the dll.
But I cannot get into the functions that the dll is offering.
I get a message that says "xyz.c was not found"
Why am I getting this message?
Does this mean that I can't get into the source code just from a DLL + .PDB?
What about a static library (.lib) built using the /Z7 option?
No, you need to have source code to be able to see the source code.
pdb (or /Z7) contains debug information which is like mapping between executable code and your source code. With pdb VS debugger knows where in source files each instruction is located, but it still needs to have source files to show you the code.
Usually pdb file stores location of source files and VS debugger knows where to find them. If you move src files somewhere else then AFAIK VS will show a popup dialog to browse for .c/.cpp file that it cannot find.
Yes, you need the source code to source debug. The .PDB only contains symbols so you will be able, for example, to view a stack trace or determine the source file name and line number of a crash. Otherwise, you need the source code.
I compiled Xcode project in debug mode. however, while running it from VM with lldb (or any other remote machine), I cannot see any debug symbols.
to resolve this I've created a soft link to the project source code in local compilation machine, so that each file will have the same path.
however, unlike local VM, in remote machine i might not have source code access.
so my question is what files should i copy from project debug outputs in compilation machine, to remote machine so that the lldb debugger will recognize target symbols, and how should i "tell" lldb to look at those new data, rather than the original symbols location (in compilation machine)
In the normal build/debug cycle lldb reads debug information from the .o files made in the course of the build. There's a "debug map" in the binary produce that points to the locations of these .o files. Since the debug map records absolute paths, if you want to use the .o files on another machine the .o files must appear in the same place on the file system as they are on the builder.
The other way to do this is to use Xcode's "DWARF + dSYM" variant of debug info generation, which builds a ".dSYM" folder that contains fully linked debug information. Then just move the dSYM & the binary to the same directory and lldb will find it. If for some reason that doesn't work, there is also an lldb command: add-dsym that you can use to manually tell lldb where the dSYM is.
I have an *.exe project that was written in one solution under vs2005 and i have a DLL file
that the *.exe project is using.
the problem is that the dll was written in adiffrent solution and when i try to make attach
to the *.exe file (after i run it) from the dll solution in order to debug the dll , i get no symbols are loaded error (and i cant debug the dll) altough symbols were loaded (i can see the *.pdb files that created after i compiled the dll solution) .
What can I do?
First check the Output window, it will show whether or not it could find debugging symbols for the DLL when it got loaded. Next, switch to Debug + Windows + Modules, right-click your DLL and choose "Symbol load information". That shows where the debugger looked for .pdb files for the DLL. Ensure the .pdb is located in one of these paths.
If the problem is not getting source code for the DLL instead of missing .pdb files, first delete the hidden .suo file in the solution directory. The next time you debug into the DLL, Visual Studio will again prompt you to provide the path to the source code file. Don't press Escape, enter the path. Another thing you can do is right-click the solution in the Solution Explorer window, Properties, Common Properties, Debug Source Files. Add the path to the DLL source code directory.
If you have the visual studio project that generates the dll, compile it in debug configuration and launch debug. You'll be asked for an executable ; select the one you have (from your other solution) and you'll be able to debug the dll.
Now if you want to debug both at once, i believe your way is correct, as long as the dll that the exe uses is the exact one that you've just compiled in your other solution. That might be the problem you're encountering.