Using the symbols window(CTRL + S), i have set WinDbg to load my symbols from a specific location.
Now when i attach my debugger and try to view the stack window, it seems like symbols aren't really loaded properly.
Now, when i use the !sym noisy command and .reload /f, i get the following info from the debugger:
So, from the third picture, why is SYMSRV is even defined? and why is it adding the GUID prefix to the end of the file?
It would've worked if it wasn't that guid windbg adds to the path. What am i doing wrong.
EDIT: after reviewing the log furthermore, i see that the debugger attemps to load the symbol from the local drive.
There are several different formats in which symbols can be stored. These are 0-tier, 2-tier and 3-tier.
0-tier is basically a flat list of files, which is suitable if you have just built your program and all the PDBs are located in one folder. If you enter a local path like c:\path or server share like \\server, WinDbg should consider a 0-tier store layout, but might try others as well.
The problem is that you can only store one version of PDBs in a 0-tier store, which is why the 2-tier and 3-tier symbol stores exist. When symbols are added to such a store, it will consider the GUID, so it is possible to store several versions of the same program. 2- and 3-tier symbol stores should start with srv*. The exact difference between a 2-tier and a 3-tier store is explained in Channel 9 episode 87 and it's possible to convert a 2-tier store into a 3-tier store.
Do not confuse the srv* symbol path syntax with the SYMSRV: debug output. IMHO the SYMSRV: is just a debug message of the symsrv.dll, so nothing to worry about.
The truth about loading symbols can only be monitored with Process Monitor. Not all location where WinDbg searches for symbols are logged, even in the noisy mode.
In addition to the symbol path, DLLs contain a reference to the local path of the PDB and WinDbg will consider this path, independent of the symbol path settings.
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'm trying to debug a memory dump, using Visual Studio, as managed, but this fails with following error message:
Managed debugging is not available for this minidump.
A required library for managed minidump debugging,'mscordbi.dll', version '4.0.30319.0', could not be located.
Restart your debug session after trying one of more of the following steps:
If this computer is not currently connected to the internet, connect so the dll can be downloaded from Microsoft.
Specify the path to 'mscordbi.dll' in Symbol Settings under Debugger options.
Select 'Debug with Native Only'.
While checking my Symbol Settings, there are following Symbol file (.pdb) locations (all are checked):
Environment Variable: _NT_SYMBOL_PATH
Microsoft Symbol Servers
C:\Dump_Repository\... (not relevant for this question)
A cache directory is foreseen, and the automatic loading preference is set to Load all modules, unless excluded. The only excluded one is user32.dll.
The value of the _NT_SYMBOL_PATH environment variable is the following:
cache*;srv*C:\Dump_Analyse*C:\build_machine1;cache*;srv*C:\Dump_Analyse*\\build_machine2\Development\Symbols;cache*;srv*C:\Dump_Analyse*\\build_machine1\Symbols;cache*;srv*https://msdl.microsoft.com/download/symbols;cache*;srv*C:\ProgramData\dbg\sym
In the mentioned directory C:\Dump_Analyse, there is a directory mscordbi.dll, with three subdirectories, each containing the mentioned mscordbi.dll DLL:
Prompt>find ./ -name "mscordbi.dll" 2>/dev/null
./Dump_Analyse/mscordbi.dll (this is a directory)
./Dump_Analyse/mscordbi.dll/4BA1DA2Deb000/mscordbi.dll
./Dump_Analyse/mscordbi.dll/563C0E8E10b000/mscordbi.dll
./Dump_Analyse/mscordbi.dll/583E5AAD10b000/mscordbi.dll
The two last ones seem not that relevant, but the first one has file version 4.0.30319.1 (which is very near to the requested version).
My computer is connected to the internet, my account seems to be ok (I have recently modified the password of my Windows account, but I'm logged in on Visual Studio under another account).
Does anybody know what might be happening here and how I can solve this issue?
The problem is solved:
While trying further, I wanted to clear the symbol cache, which did not work (a user permission was said not to be correct).
That cache symbols was a directory, containing a tilde character: ~ (something like C:\Users\Dominique~1\AppData\Local\Temp\SymbolCache).
I've replaced this by the real directory name (by clicking the Browse button):
C:\Users\DominiqueDS\AppData\Local\Temp\SymbolCache
In other words (for searching purposes): in Visual Studio Symbol settings, the symbols cache directory should not contain a ~ (tilde) character.
I use a symbol store on a network drive to collect debug symbols for our application. The symbols are used while debugging a crash dump file that has been loaded into Visual Studio. I have Powershell scripts in place that manage deleting ‘old’ versions of symbols. Or, so, I thought.
Recently, while working on another script, I noticed that using symstore to delete symbols doesn’t actually delete anything. When I use symstore to delete symbols I see a “0000000161.deleted” file in 000Admin folder for example. This file contains entries for the associated debug symbols. It contains entries like:
"Aggregat.pdb\B4E7044117F0469CB321E9FA9003E4CA5","C:\temp\pdbs\1823\Aggregat.pdb"
The first entry above is the folder for the associated debug symbols for the ‘Aggregat’ module. I would expect that when I delete symbols using the transaction ID, that the corresponding folders (ie. B4E7044117F0469CB321E9FA9003E4CA5) would also be removed. It appears like that’s not the case.
Is my assumption correct? Am I responsible for the full cleanup of the symbols store structure?
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).
I have used vtune several times in the past, usually without too much trouble. Unfortunately the gaps between each use are often so long that I forget some aspects of how to use it each time. I know that the line number and symbols information needs to be stored somehow. I thought that all that was required was to compile your exe with "Program Database" (/Zi), but I have just done a sampling and found that vtune reports there are no symbols available.
Is there anything I missed?
There are two options for debugging (check $> cl /?):
/Zi enable debugging information
/ZI enable Edit and Continue debug info
Make sure that you have .pdb and manifest file (if generated).
It's not related but maybe turn off optimizations as well.
Like Bua mentioned, you definitely need to be compiling with debugging information enabled. If the pdb files are in the same directory as the exe that you're profiling, then it should be able to find them. If not, you can also try explicitly adding the path to the pdbs in config -> options -> directories. alt text http://software.intel.com/file/21331 Add an item with your symbols directory. You might also want to add a symbol server and symbol cache, because then you'll get symbols for all of Microsoft's public binaries. The image above shows how to add a symbol server with a symbol cache at c:\websymbols. Generally, the format for a "symbol server" is a string of the form:
an example:
SRV*C:\MySymbolCache\*http://msdl.microsoft.com/download/symbol
of the form:
SRV * [CACHE] * [SYM SERVER PATH]
Hope this helps!
The problem has been solved: It turned out that it was a mistake in setting the working directory; "/Zi" appears to be all that is required after all. I don't need to switch off optimization.