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).
Related
Issue: I have generated the .msi file (installer) and once I installed that installer when i am trying to open, it is not responding.
To find the root cause, I am using WinDbg and opening the executable (PowerChart.exe) that has generated in the below path:
C:\Program Files\EMR\PowerChart
I followed two approaches to load the executable but in both the approaches i am getting the errors like Symbols are not loading properly.
Approach1:
In the "symbol Search Path", i set "srv*c:\symbols*https://msdl.microsoft.com/download/symbols
(For this I created the "symbols" folder in the "C" drive, so that it will download the symbols and place it in "symbols" table)
Then opened the PowerChart.exe from "Open Executable..." in the File menu option of the Windbg.
Then i am getting the below errors:
Error: Symbol file could not be found. Defaulted to export symbols for ntdll.dll
When i run the URL (https://msdl.microsoft.com/download/symbols) in the browser it is showing "The Data you requested cannot be retrieved"
And also do we need to connect to internet to download these symbols?
Is it the correct symbol path that i have given?
Please help me to resolve this error.
Approach2:
When the .msi file is generated it also generated the .pdb file (EMR.pdb)in the below path:
E:\Code\EMR\bin\debug\en-US
so, what i have done is, I have attached the pdb path in the "symbol Search Path"
E:\Code\EMR\bin\debug\en-US
Then open the PowerChart.exe from "Open Executable..."
Then i am getting the below errors:
Error: Symbol file could not be found. Defaulted to export symbols for ntdll.dll
Symbol Loading Error Summary.
Module name Error
ntdll PDB not found : E:\Code|EMR\bind\debug\en-us\symbols\dll\ntdll.pdb
I am not sure whether this approach is correct or not.
Please help me and suggest how to resolve symbol errors?
From what you have shared I can see that the it is 'ntdll.dll' where you are having an issue. The symbols for that should really be coming from "srvc:\symbolshttps://msdl.microsoft.com/download/symbols, but that i sseemingly not happening.
If I may sugest you stick with the second approach and additionally set an envronment variable, i.e. '_NT_SYMBOL_PATH' to 'srvC:\symbolshttp://msdl.microsoft.com/download/symbols'.
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.
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.
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 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.