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
Related
I use to take always a look at the final binary executable or DLL after debugging and creating a file with any IDE. Now I am trying Visual C++ 2010, in the search for the best release, without trash or unnecessary references.
So, I created a new solution with two projects: an executable and its DLL. VC++ created a lot of intermediary files between the code and the final file. I opened the .exe and the .dll with a hexadecimal editor and saw something that I don't like. Somewhere inside the file there's an absolute path to the .PDB file.
Why? How can I remove it from VC++?
There must be some pre-processor command for this. What is the use of an absolute path to a .PDB file, like "D:\My Projects\Project1\Release\Project1.pdb" inside the binary of a file that will be distributed on computers with different folders? Besides that, I don't like to see one of my drive's paths saved inside a binary file that I want to share with other people. I am in Release mode, I don't see the use of that unnecessary information. How could I remove it?
You can use /pdbpath:none (or /pdbaltpath:%_PDB% on newer versions of link.exe) to remove the full qualified path name of the PDB file, but keep the name and extension of the PDB only. Keeping the name (and extension) of the PDB for released images is your only way to debug an image that is buggy. Windows images almost always keep the name and extension of the PDBs!
Read the PDB Files documentation on MSDN:
A program database (PDB) file holds debugging and project state information that allows incremental linking of a Debug configuration of your program. A PDB file is created when you compile a C/C++ program with /ZI or /Zi or a Visual Basic/C#/JScript .NET program with /debug.
In Visual C++, the /Fd option names the PDB file created by the compiler. When you create a project in Visual Studio using wizards, the /Fd option is set to create a PDB named project.PDB.
Note that the absolute path is mentioned in the documentation:
The Visual Studio debugger uses the project.PDB file created by the linker directly and embeds the absolute path to the PDB in the EXE or DLL file.
You can always go to Project Properties > Linker > Debugging > Generate Debug Info and set it to No.
If you you cannot rebuild your module (i.e. using the linker switch /PDBPATH:NONE which Microsoft seems to have removed support for), I wrote the peupdate tool for this purpose, as long as you don't mind using a 3rd-party tool. Peupdate can be used to list, remove or change the PDB string in an executable module. Below are some examples:
peupdate -c <module_path> //clear entire PDB path
peupdate -k <module_path> //remove PDB path, but retain filename
peupdate -u <newpath> <module_path> //set your own path string
To remove the path of the PDB file out of the EXE file without loosing debug info, you could embed the PDB file inside the EXE file.
Properties => Build => Advanced (Build Settings) => Debuginfo => Embedded
I have compiled an exe file in Visual Studio 2013, and it depends on some external files to function. I want to keep those files in the same folder that the exe is in. When I run the .exe by clicking on it in file explorer, it loads the files fine. However, when I run it from Visual Studio, it is unable to run because the PATH variable does not include the directory with the necessary files. How can I configure my project to run the program with a modified path variable so that it can access the files properly?
As far as I understand you question correctly. I suspect that this is an issue related to the different directories when you execute. In Visual Studio (to my knowledge), you have a folder named Debug and a second folder named Release.
You may choose in Visual Studio to run the program in either debug or release mode. But you might not have the required files neccessary in both directories.
For example:
I've made a program that reads "Hello World!" from hello.txt, and displays this in the dialog window as a string.
If I store the file in the Release directory, the executable will run fine outside the IDE, when just launching the executable file.
However, if you run the application in debug mode through the IDE (Visual Studio), the program will not find the neccessary file. The program is looking for the file in it's current directory (Debug).
A quick fix to this is to copy the required files to the current working directory. Eventually have a duplicate set of files in both directories at all times.
Hope that I did understand you correct, and that my answer helps you. :)
The project runs okay in the debug mode of Visual Studio, but when I tried to double-click the exe generated, it says some dll is missing. When I copied the missing dll beside the exe and double-click again, no error message dialog appeared but also nothing happened(the project has Qt-based GUI and reference some external png files).
How does Visual Studio run the exe ? How can I run the exe on my own ? Should I create a installer for the project to make it run on other computers?
you would need to either build statically or provide the required dll files.
the page at http://www.tapkaa.com/2013/05/what-dll-files-are-required-to-run-an-application-developed-with-visual-c/ tells how you can find the missing dll files.
When a process needs to load a DLL by name (without a full path to it), it will check several different places. One of those places may be the current working directory. (The details of the search path are complicated by history and security issues. You can learn the details by looking up LoadLibrary and SetDllDirectory on MSDN.)
In Visual Studio, if you look at the Properties page for the project, and click the Debugging tab, you'll see what directory is set as the working directory when you launch the program from Visual Studio. When you double click on an icon, I believe the working directory will be the directory of the executable file. If these are different, that could explain why you're able to find the DLL in one case but not in the other.
If you're calling LoadLibrary directly, the best thing to do is to always give the full path to the library. Typically, you GetModuleFileName to find out the full path for the executable, then replace the filename portion with the name of the DLL or a relative path from the executable to the DLL.
If you're failing to load an implicitly-linked DLL, then you probably need to make sure your DLL is in the same directory as the executable file.
I got a minidump from a server on which my native c++ app was running. I also have the exe and pdb files. I am able to open the minidump using Visual Studio 2005 Pro and it correctly loads the symbols from the pdb file.
I run the debugger (F5) and it shows me that it crashed. When I click on the stack trace to see where, it tells me that it can't find the source code "There is no source code available for the current location.".
How do I tell Visual Studio where the source code is?
My exe is an optimized release build that I build with a pdb file.
From this MSDN page:
In the Solution Property Pages, you can change the directories where the debugger looks for sources files and tell the debugger to ignore selected source files. See Debug Source Files, Common Properties, Solution Property Pages Dialog Box.
Make sure you supply VS with the sources that correspond to the binaries and PDB files.
Normally, VS should ask you where the sources are when first double-clicking a stack frame. I ran into a problem where VS would pop up the There is no source code available for the current location. dialog when clicking on some stack frames only, but display the source for others. This turned out to be because the /Zi flag was not set for some projects, causing the link back to the source files to be missing. This flag can be set in Project Propery Pages > C/C++ > General > Debug Information Format.
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.