When debugging a c++ solution in Visual Studio 2010, It says "No symbols have been loaded for this document." And when I check in debug / modules / <dll I cant debug>.dll / symbol load information It is looking for a pdb with the wrong name.
So, where can I set the name of the symbol it is looking for? I looked all through the command line options, and I can't find such a name anywhere.
I've tried to do a rebuild, a clean + build, but neither helped.
There are two places in which .pdb information is collected
1) C++/Output Files/Program Database Filename
2) Linker/Debugging/Generate Program Database file
By default, 2 is set but 1 is normally set to v100.pdb (for VS2010). If both these files are set to point to the same file, then you should get the symbolic information.
Try searching all PDBs (and .idb) and manually delete them.
The reason some include path is set to that library's directory that contains your PDBs, its .pdb file seems to be used by the VS debugger.
The solution is to delete these .pdb files or to rebuild all libraries.
Related
I am trying to redo steps of a Linux 'hacking' tutorial in Windows.
In one step the program is debugged using GDB.
The command ptype is used in order to the class definitions of the class Player which is located in a DLL called GameLogic.dll.
I try to mimic this exact step and use ptype on GDB I installed for Windows using MINGW. However, I cannot see any definitions since no symbol file is loaded:
(gdb) ptype Player
No symbol table is loaded. Use the "file" command.
A symbol file GameLogic.pdb is located inside the DLL directoy. It is provided intentionally to investigate the program's structure further.
Yet, using the file command I cannot load it into the program:
(gdb) file "E:/xx/PwnAdventure3/Binaries/Win32
/GameLogic.pdb"
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
"E:/xx/PwnAdventure3/Binaries/Win32
/GameLogic.pdb": not in executable format: File format not recognized
This error could be due to the different executable format used by Windows.
However, there are other methods which I found online while researching this issue:
add-symbol-file filename address
set debug-file-directory <directory>
I cannot figure out how I should use these in this particular case. Since in the examples they provide a .o file as filename. Even though I could provide the .pdb file I also need an address (I suppose it's the address at which the DLL is loaded?).
Defining a different directory via set debug-file-directory <directory> which contains the .pdb file does not work.
I also tried different debuggers like OllDBG, WINDBG, Visual Studio and IDA Pro. In Visual Studio I can see that the symbols where loaded but I cannot find any method to further dig into the disassembled file. Only in OllyDBG I can see that the methods which belong to the Player class, e.g., Player::SetJumpState(bool) are correctly depicted.
I also must admit that I don't have much experience with these tools.
Which steps are necessary in order to load the symbols for the DLL file in GDB additionally so that the ptype command works?
Is there another (better) method using one of the mentioned programs to recreate the Player class along with it's local variables?
Regards
Unfortunately GDB does not support reading symbols from PDB files currently, even on Windows. WinDBG/Visual studio should work though.
I am using VS2015 debugger on my C++ app. When I start the app, debugger gives the message
Loaded 'C:\MyDir\Working\x64\Debug\MyApp.exe'. Cannot find or open the PDB file
As a consequence, I cannot set breakpoints.
There is a .pdb file in the same directory as the .exe, but it doesn't match, according to VS debugger, and also according to WidDBG Symchk. Symchk does not provide the reason for the mismatch, even with /v option.
Complete rebuild does not make this problem go away. It is only occurring for debug build, and it just started today. Before today, there was no problem with mismatched pdb's, either for debug or release builds.
The VS options I am using are:
C++: Debug Information Format=Program Database (/Zi), Program Database File Name=$(IntDir)%(Filename).pdb;
Linker: Generate Debug Info=Optimize for debugging (/DEBUG), Generate Program Database File=$(OutDir)MyApp.pdb, Generate Full Program Database File=Yes.
The pdb files for the individual objects appear in the intermediate directory, and MyApp.pdb appears in the output directory, along with MyApp.exe.
Now, here's the weird part: when delete the existing MyApp.pdb and then relink, a new .pdb file appears in the output directory with a current mod time. While the linker is running, the pdb file grows to be large (~70 MB), but as the linker completes, the pdb file suddenly becomes small (~4 MB), and the mod time changes to a few hours earlier today. This is very suspicious, and probably accounts for the pdb mismatch.
The linker's final output lines are
Finished searching libraries
MyApp.vcxproj -> C:\MyDir\Working\x64\Debug\MyApp.exe
MyApp.vcxproj -> C:\MyDir\Working\x64\Debug\\MyApp.pdb (Full PDB)
How can I force VS to produce a matched and correct pdb file for the debug build?
UPDATE: The problem was that there is a pdb file MyApp.pdb created in the intermediate directory (it is the pdb file created by the compiler for MyApp.cpp). For some reason, the linker replaces the "real" pdb file with this one at the end. Since they have the same name, MyApp.pdb, Symchk doesn't show a name mismatch (although there may be a timestamp mismatch that isn't evident).
It is not obvious how the debugging info for MyApp.cpp can be included in the final MyApp.pdb.
I want to be able to dynamically load and unload DLL projects at runtime. For this to work I have to make sure that each time I rebuild my project in Visual Studio the .pbd file generated has a pseudo-random generated name as (random file-path valid string).pbd.
This is because the debugger forces me to abort debugging before rebuilding otherwise.
I first tried creating a custom pre build tool that ran a .bat file that created a system enviroment variable like this:
set TIMESTAMP=%DATE:/=-%#%TIME::=-%
set TIMESTAMP=%TIMESTAMP: =%
setx buildrandomvar %TIMESTAMP%
And that worked fine, I checked the registry. But no matter what I did I just could not reference "buildrandomvar" as a part of the .pdb file name. The result was just an empty ".pbd".
My Program Database File Name setting is: $(OutDir)$(TargetName)$(buildrandomvar).pdb
I would really appreciate any help at all with this issue because I just can't get this to work.
I found the answer and I'll just put it here in case anyone ever needs it.
In Visual Studio, right click your project, go to Properties -> Linker -> Debugging -> Generate Program Database File and enter
"$(OutDir)$(TargetName)-$([System.DateTime]::Now.ToString("HH_mm_ss_fff")).pdb"
This should generate your pdb with a timestamp in the file name which is technically pseudo-random.
In order to trace a crash in a Qt which only happens on a Windows 8 user machine I set up a local symbol server to use for debugging crash dumps.
First I did a full build with the following flags set:
QMAKE_CFLAGS_RELEASE += -Zi
QMAKE_CXXFLAGS_RELEASE += -Zi
QMAKE_LFLAGS_RELEASE += /DEBUG /OPT:REF
and built an installer using Windows Installer and a VS deployment project. Then I ran the following symstore.exe command:
C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64>symstore.exe add /r /f C:\builddir\*.* /s "C:\Users\Sam\symbols" /t "Application" /v "rev xxxx" /c "test add"
This created the appropiate dll, exe and pdb folders inside C:\Users\Sam\symbols.
Then I installed on the user machine and generated a minidump file through Process Explorer. I tried loading in the dump to Visual Studio and adding C:\Users\Sam\symbols to the symbol file locations but no matching symbols could be found for my binaries.
Then I tried loading it into WinDbg64 (this being a 64bit application). I set !sym noisy set the symbol path with .symfix C:\Users\Sam\symbols and reloaded with .reload /f. This did not have any success either and only export symbols where loaded. For example:
QtGui4 No data is available : SRV*C:\Users\Sam\symbols*http://msdl.microsoft.com/download/symbols
The SYMSRV client failed validating the GUID for the module, or the
module does not have the debug header information.
This happens for all modules but I would not expect it at all for the Qt components since these are not built as part of the regular build and even setting the symbol folder to the lib folder directly containing the pdb files doesn't help.
I then tried running ChkMatch.exe against the executable and the pdb file in my symbol store. The signature for the executable matched the folder the pdb was in which indicated that they should be a match but I then got the following error:
Debug information file:
Format: PDB 7.00
Error: PDB header - too many pages in root stream.
I ran ChkMatch.exe again against the installed executable just in case but got the same signature and the same error.
Edit:
I tried setting symopt+0x40 which should make WinDbg use the pdbs anyway without checking the signature GUID too closely. However it is still not loading anything at all. Extra output:
SYMSRV: C:\Users\Sam\symbols\QtGui4.dll\5202030497e000\QtGui4.dll not found
...
SYMSRV: C:\Users\Sam\symbols\QtGui4.dbg\5202030497e000\QtGui4.dbg not found
SYMSRV: http://msdl.microsoft.com/download/symbols/QtGui4.dbg/5202030497e000/QtGui4.dbg not found
DBGHELP: .\QtGui4.dbg - file not found
DBGHELP: .\dll\QtGui4.dbg - path not found
DBGHELP: .\symbols\dll\QtGui4.dbg - path not found
DBGHELP: QtGui4.dll missing debug info. Searching for pdb anyway
DBGHELP: Can't use symbol server for QtGui4.pdb - no header information available
DBGHELP: QtGui4.pdb - file not found
*** ERROR: Symbol file could not be found. Defaulted to export symbols for QtGui4.dll -
DBGHELP: QtGui4 - export symbols
The folder in C:\Users\Sam\symbols\QtGui4.dll has the name 4AA92D1B712000 and contains what should be the correct dll.
I managed to resolve this myself eventually. Firstly I had to delete and recreate my symbol store from scratch using the above steps. I think I must have messed up my store initially by running symstore.exe twice with the same version number on different folders.
Once I had done this I could then load in crash dumps and see the symbols for the Qt libraries, but only up to about twenty frames and none of the other modules were loaded. I then wanted to copy this stack but couldn't from the stack window in WinDbg and so found the k command to print out the stack. This was an 'Aha!' moment because the k command printed out much more than the stack window and revealed that a stack overflow had occurred. I found that an additional parameter could be passed in for the depth of the stack to be printed and a k 0xFFFF printed out the entire stack.
For working with minidump you should upload binaries to symstore too
I have a c++ executable for windows and a minidump that I am trying to analyze using windbg.
I copied the assosciated pdb and minidump into the same folder and set the symbol path.
Windbg however complains
DBGHELP: c:\logs\marketdepthserver crashdump\SFMarketDepthServer.pdb - E_PDB_CORRUPT
Besides concluding the file is corrupt.. is there anything else I can determine from this or is there a workaround that will allow me to load the pdb.
!sym noisy : tells you why you failed to load symbols
.reload /f foo.exe - to force load
.reload /f /i foo.exe - to force load with mismatched symbols. This may give you some valuable info.
This is not the answer, but this might work for you as well..
I also got this error long time back. I don't know the reason/solution for this, but I remember that I copied both the files (.exe and .pdb) to a new folder and then reloaded symbols (.reload) after specifying the new symbol path (.sympath) and that worked. (Rebuilding was also not working).