I'm trying to learn about reading dump files, so I made my small APP crush, and created a dump for that process from task manager.
I tried to open the .dmp file, both from VS10 and windbg.exe, and got an error that the symbol files are missing. I specified the path of the symbol files as the directory where the .pdb files are located :
..\Visual Studio 2010\Projects\CachedQueryTester\CachedQueryTester\bin\Debug
but I still get the same error, both on VS10 and windbg.exe,
Any Idea?
You may also need symbols from Microsoft , try to enter
0:000> .symfix
in windbg
From your configuration, you should not have to specify any debug symbol path, because the path of your symbols are stored in the executable. To be sure, you can open a Visual Studio Command prompt and type
dumpbin CachedQueryTester.exe /HEADERS
In the output, you should have a 'Debug Directories' entry containing the full path of the pdb.
If this is not the case, check you have specified to generate a PDB file (Configuration Properties / Linker / Debugging / Generate debug info);
You can also try to ask WinDbg for the location it looks for. In order to do this, open your dump file from within WinDbg, type '!symnoisy' and reload the symbols (.reload /u then .reload and kb). It will tell you the locations it looks for.
Related
I am using Conan package manager on Windows to create a package. The conan command to create the package copies files to a folder within %USERPROFILE%\.conan (or C:\Users\xxxxxxx\.conan). Then from this location it builds a Visual Studio project and ultimately calls doxygen.exe to create a .chm help file in a post-build command. The doxygen command fails with:
error : failed to run html help compiler on index.hhp
Further investigation reveals the hhc.exe command executed by doxygen is failing with:
C:\Users\xxxxxxx\.conan\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation>"C:/Program Files (x86)/HTML Help Workshop/hhc.exe" html\index.hhp
HHC5010: Error: Cannot open "C:\Users\xxxxxxx\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation\html\Module.chm". Compilation stopped.
Close inspection reveals that in the error message, the ".conan" folder is missing. Sure enough, I confirmed that hhc.exe fails when the index.hpp resides in a folder that has a parent folder that starts with a ".".
Attempts to resolve this:
changing the Doxyfile setting OUTPUT_DIRECTORY to "$(TMP)/DoxygenModule" resolves the error, but creates the .chm file in another location, which I do not prefer.
navigating to the 8DOT3 name of the ".conan" folder, which is "CONAN~1", to run the hhc.exe command, succeeds, but unfortunately I have no way of getting conan to use this 8DOT3 path for creating the package. E.g. C:\Users\xxxxxxx\CONAN~1\...
I can live with the using the %TMP% folder but would prefer generating the .chm in the current folder. Anyone have any ideas?
HTML Help Workshop v1.31 is installed on my machine at C:\Program Files (x86)\HTML Help Workshop, probably from a Visual Studio installation (not sure). I attempted using a version downloaded from Microsoft website (v1.30) as well, which made no difference.
Other info: Conan version 1.18.0, Doxygen version 1.8.14, Windows 10 Version 1809
Unfortunately not a solution, but this is a known limitation in the hhc.exe, see: https://social.msdn.microsoft.com/Forums/en-US/0681145c-223b-498c-b7bf-be83209cbf4e/issue-with-html-workshop-in-a-windows-container?forum=visualstudiogeneral
HTML Help 1.x command line compiler hhc.exe cannot compile CHM file to folder whose full path contains folder name starting with dot. If you have that problem, you probably specified output path with folder starting with dot, e.g. "d:\My files.NET\documentation". You can use dots in folder names but not at the beginning.
Edit 2019-11-15:
I've just pushed a proposed patch to github (pull request 7402, https://github.com/doxygen/doxygen/pull/7402).
This proposed patch changes inside doxygen from the current directory to the short named current directory, but just for the HTML Help compilation.
Edit 2019-11-16:
Code has been integrated in the master version on github.
This is not an answer either. Actually, you found the answer and workaround[s] yourself.
Use OUTPUT_DIRECTORY to specify a directory containing no folder names beginning with periods.
The error you described is a known issue of the MS HTML Help compiler. More general, the HTML Help compiler does not like some folder and file names. Try and stick with these characters _, a..z, A..Z, 0..9. Do not use these signs in particular ., -, # .
Please note that the proprietary CHM file format is about 20 years old (Windows 95, ...). HTML Help is in maintenance mode, which means no new features and bug fixes are expected for either the runtime or the compiler. All mainstream development on HH has stopped.
There is no way to avoid this error if a directory name above begins with a period. Not even if only the necessary files are written by Doxygen and compiling of the index.hhp is done by a third-party tool like FAR HTML using your path that contains .conan. This is because all applications are using the faulty HHA.dll.
The above applies of course to the entire workflow you have described. Maybe you can interrupt it.
Doxygen can be configured not to call the HTMLHelp compiler. Just uncheck the GENERATE_HTMLHELP option (DoxyWizard: Experts > Topics > HTML). You have all files generated by Doxygen in your preferred output directory - but of course without the CHM file. This can be imported later e.g. by HelpNDoc and compiled as a CHM file in another location.
If you can interrupt the workflow and can also make changes to Doxygen's settings, then a preference setting of OUTPUT_DIRECTORY to e.g. C:/CacheMenu/CONAN~1/DOXYGE~1 also works as expected (here used as test case).
No matter what you do, your workaround and copy and paste from another directory outside is a quick solution at this stage. Please note the EDIT in #albert's answer.
I'm using UMDH 6.1.7659 out of the latest Windows Debugging Kit. I'm wanting to try and generate a dmp file that I can look at in WINDBG to investigate a memory leak in an unmanaged 64-bit C++ EXE:
set _NT_SYMBOL_PATH=<.PDB_file_directory>
umdh -p:<valid PID> -f:c:\temp\dump1.dmp
When I try and open up the DMP file in WinDbg (Version 1607), I see this:
Loading Dump File [c:\temp\dump1.dmp]
Could not match Dump File signature - invalid file format
Could not open dump file [c:\temp\dump1.dmp], Win32 error 0n87
"The parameter is incorrect."
**** DebugClient cannot open DumpFile - error 80070057
DUMPCHK on the same DMP file gave me the same result.
Is UMDH not compatible with WINDBG anymore?
I believe you got some misunderstanding,
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/using-umdh-to-find-a-user-mode-memory-leak
UMDH generates its own data format (a text based data structure), which is clearly not process dump files for WinDbg to analyze.
I want to install the lates version of MUSCLE downloaded from http://www.drive5.com/muscle/downloads.htm
named muscle3.8.31_i86win32.exe . As the guidelines
http://www.drive5.com/muscle/manual/install.html
says I have to write the below line in the command prompt:
C:\Program Files (x86)\muscle3.8.31_i86win32 -in seqs.fa -out seqs.afa
However, I faced this error:
MUSCLE v3.8.31 by Robert C. Edgar
http://www.drive5.com/muscle This software is donated to the public
domain. Please cite: Edgar, R.C. Nucleic Acids Res 32(5), 1792-97.
* ERROR * Cannot open 'seqs.fa' errno=2
I am sure the file exists in the mentioned directory, but I don't why has this happened and how can I fix it. Any idea?
The program is reporting that the OS reported that the file doesn't exist. (That's what errno 2 is.)
Testing reveals that relatives paths are resolved relative to the current work directory as expected.
So, your operating system is saying there's no file named seqs.fa in the current work directory.
Double check the name of the file you have. Keep in mind that File Explorer hides known file extensions by default so using dir would be more reliable.
I've set Windbg up as the debugger for my development system. And, sure enough If I induce a trap in some of my programs up pops the dialog; I click the debug button; and the source file is displayed with the faulting line highlighted. Mouse over and local vars windows work.
Today, I writing a fairly simple standalone C app, made a mistake and got a trap. But this time hitting debug no source; just the console window.
If I set a breakpoint on main and hit f5, sure enough the source code appears, but the mouse-over variables doesn't work nor the local variables window.
The program is compiled for debug /Zi /Od and the .pdb (& .ilk?) are right there along side the source and executable.
If I invoke the executable under windbg manually, same thing. No source until a run to a break point within it. Then no local var knowledge.
If it can find the appropriate information for one app; why not the other?
Cheers, Buk.
Windbg doesn't know the location of the PDBs, even if they are in the same folder like the exe. Add the location of the PDBs under File->Symbol File Path (CTRL+S).
Debugging symbol issues
If the symbols (PDBs) do not work as expected, use the
!sym noisy
command to debug the issue. This will display additional information about paths where WinDbg looks for PDB files.
If you change the symbol paths to fix the issue (using .sympath, .sympath+, .symfix or .symfix+), be sure to issue a .reload afterwards.
Checking correctness of symbols
If changing the symbol path still does not help, maybe the PDB does not match the executable (should not happen if you just compiled it). Just to be sure, you can use the symchk tool which comes with WinDbg.
Symchk /if <exe> /s <symbol path> /av /od /pf
/if = input is a file
/s = symbol file path
/od = all details
/av = verify
/pf = check if private symbols are available
or get ChkMatch which is a bit easier to use
ChkMatch -c <exe file> <pdb file>
Workspaces
(a question in the comments)
Don't worry about the workspaces and that WinDbg asks to save. You cannot understand the concept without reading about it.
I'm trying to debug an NDK project on Windows using Eclipse (Kepler), but GDB won't find the symbols for the .so file, because the direction of the slashes in the search path are incorrect. Using NDK r9 and SDK 22.2.1, when I try and run the application, GDB shows:
warning: Could not load shared library symbols for 64 libraries, e.g. /system/bin/linker.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
warning: Unable to find dynamic linker breakpoint function.
GDB will retry eventurally. Meanwhile, it is likely that GDB is unable to debug shared library initializers or resolve pending breakpoints after dlopen().
No symbol table is loaded. Use the "file" command.
No symbol table is loaded. Use the "file" command.
No symbol table is loaded. Use the "file" command.
The "No symbol table is loaded..." lines appear once for each breakpoint set in my library. The problem seems to be that GDB isn't finding the unstripped .so file, as the search path contains backslashes instead of forward slashes. If I pause the program and execute the following GDB commands, this is the output I get:
show solib-search-path
The search path for loading non-absolute shared library symbol files is C:\\Users\\Username\\Projects\\Project\\Android/obj/local/armeabi-v7a/.
info shared
From To Syms Read Shared Object Library
0x4003fff0 0x4006db40 Yes C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/libc.so
0x5bda8598 0x5bf5aa50 No C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/libProject.so
If I then update the solib-search-path to use forward slashes, I get this:
set solib-search-path C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/
warning: Could not load shared library symbols for 74 libraries, e.g. /system/bin/linker.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
warning: Unable to find dynamic linker breakpoint function.
GDB will retry eventurally. Meanwhile, it is likely
that GDB is unable to debug shared library initializers
or resolve pending breakpoints after dlopen().
info shared
From To Syms Read Shared Object Library
0x4003fff0 0x4006db40 Yes C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/libc.so
0x5bda8598 0x5bf5aa50 Yes C:/Users/Username/Projects/Project/Android/obj/local/armeabi-v7a/libProject.so
After which point GDB will successfully hit breakpoints in the native code. The gdb.setup file in the libs\armeabi-v7a folder has the line:
set solib-search-path ./obj/local/armeabi-v7a
But I'm not sure where this path gets changed into an absolute path. I'm guessing it's at that point that GDB uses the path with backslashes instead of forward slashes, but I'm not sure where that happens. I did try modifying the Android NDK build scripts that create the gdb.setup file, and even tried putting in a different path, but the output from show solib-search-path was just the same, so I'm not even sure GDB is using that search path. Has anyone come across this problem before, or does anyone know how I can get GDB to start up with the correct search path when I run from Eclipse?
I think this may have just been GDB not loading the symbols until a later time. I did have a delay before loading the project's .so, to allow GDB time to connect. I moved the delay until after the call to loadLibrary, and it seems to be picking up the symbols fine now.