I created a simple console demo application in VS2015 which simulates a crash. I run the executable with windbg to debug it for demo purposes. The application runs and crashes as expected.
But here is when windbg is weird.
I can't see the code corresponding to call-stack functions when I have built it on same machine. The source code line next to call stack is not where source code is, it almost has no reference to my sample code (a single main.cpp file).
0:000> kb
# ChildEBP RetAddr Args to Child
00 0036f7e8 77a18e12 ffffffff 00000000 00000000 ntdll!NtTerminateProcess+0x12
01 0036f804 756c79c4 00000000 77e8f3b0 ffffffff ntdll!RtlExitUserProcess+0x85
02 0036f818 0f4891b8 00000000 0036f840 0f48916c kernel32!ExitProcessStub+0x12
03 0036f824 0f48916c 00000000 0036f84c 0036f850 ucrtbased!exit_or_terminate_process+0x38 [d:\rs1\minkernel\crts\ucrt\src\appcrt\startup\exit.cpp # 130]
04 0036f840 0f489452 00000000 00000000 00000000 ucrtbased!common_exit+0x5c [d:\rs1\minkernel\crts\ucrt\src\appcrt\startup\exit.cpp # 265]
05 0036f854 00e42348 00000000 c0bb032f 00000000 ucrtbased!exit+0x12 [d:\rs1\minkernel\crts\ucrt\src\appcrt\startup\exit.cpp # 278]
06 0036f8b0 00e421cd 0036f8c0 00e424e8 0036f8cc Project1!__scrt_common_main_seh+0x168 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl # 262]
07 0036f8b8 00e424e8 0036f8cc 756c336a 7efde000 Project1!__scrt_common_main+0xd [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl # 296]
08 0036f8c0 756c336a 7efde000 0036f90c 779f9902 Project1!wmainCRTStartup+0x8 [f:\dd\vctools\crt\vcstartup\src\startup\exe_wmain.cpp # 17]
09 0036f8cc 779f9902 7efde000 7dbc800d 00000000 kernel32!BaseThreadInitThunk+0xe
0a 0036f90c 779f98d5 00e4134d 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70
0b 0036f924 00000000 00e4134d 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b
when I run lm Project1.exe, it doesn't understand Project1.exe
0:000> lm Project1.exe
Unknown option 'P'
Unknown option 'r'
Unknown option 'j'
^ Syntax error in 'lm Project1.exe'
More interestingly when I run lm command, it shows C next to Project1 module which means checksum mismatched, but why? it was built on same machine and symbol files should match 100% but it apparently doesn't.
0:000> lm
start end module name
00e30000 00e51000 Project1 C (pdb symbols) C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\sym\Project1.pdb\73D98E9A3EDD4D4D8AE90DF76040737D1\Project1.pdb
0f000000 0f006000 detoured (deferred)
0f3d0000 0f546000 ucrtbased (private pdb symbols) C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\sym\ucrtbased.pdb\D9FF3B7405474C158B4E3C2FBCC108362\ucrtbased.pdb
It actually doesn't even say private pdb symbols for the main Project1.exe module almost like it can't find the symbols!?
The checksum issue is also reflected in k command
0:000> k
# ChildEBP RetAddr
00 002df984 77a18e12 ntdll!NtTerminateProcess+0x12
01 002df9a0 756c79c4 ntdll!RtlExitUserProcess+0x85
02 002df9b4 608c91b8 kernel32!ExitProcessStub+0x12
03 002df9c0 608c916c ucrtbased!exit_or_terminate_process+0x38 [d:\rs1\minkernel\crts\ucrt\src\appcrt\startup\exit.cpp # 130]
04 002df9dc 608c9452 ucrtbased!common_exit+0x5c [d:\rs1\minkernel\crts\ucrt\src\appcrt\startup\exit.cpp # 265]
*** WARNING: Unable to verify checksum for Project1.exe
05 002df9f0 012a2348 ucrtbased!exit+0x12 [d:\rs1\minkernel\crts\ucrt\src\appcrt\startup\exit.cpp # 278]
06 002dfa4c 012a21cd Project1!__scrt_common_main_seh+0x168 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl # 262]
07 002dfa54 012a24e8 Project1!__scrt_common_main+0xd [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl # 296]
08 002dfa5c 756c336a Project1!wmainCRTStartup+0x8 [f:\dd\vctools\crt\vcstartup\src\startup\exe_wmain.cpp # 17]
09 002dfa68 779f9902 kernel32!BaseThreadInitThunk+0xe
0a 002dfaa8 779f98d5 ntdll!__RtlUserThreadStart+0x70
0b 002dfac0 00000000 ntdll!_RtlUserThreadStart+0x1b
When this simple project is built on the same machine, why can't windbg not able to find things and is not producing meaningful results?
You need to set the /release switch in your project for chksum to be set the default for debug buulds is nochksum
And default for release buikds is setchksum
Unable to verify checksum for exe
https://msdn.microsoft.com/en-us/library/h8ksa72a.aspx
For using lm with modulename you need -m switch.
Like. Lm -m pro*
You can use wildcards for modname. Windbg will show all the modules matching the pattern
The. F:\dd path are from crt sources. They are available in your vs src folder. Since they are hardcoded path
You may need to copy the src folder to the exact directory structure in your local machine
Viz md f:\dd........\ and xcopy the whole src folder to that path. Windbg will pick the souces
If. You compile debug or release your pdb is not stripped they remain private pdb unless you used pdbcopy or binplace to strip the private symbols
Your stack shows terminateprocess. It means. It is past your user code you may need to open your source file manually. Using. Lsa ls commands
Typing from mobile so i may edit this further to add info
when I run lm Project1.exe, it doesn't understand Project1.exe
The lm Project1.exe command fails for 2 reasons:
The module name is Project1 and not Project1.exe
The command is missing another m: lm m Project1
It actually doesn't even say private pdb symbols for the main Project1.exe module almost like it can't find the symbols!?
I'd say that's normal for a release build. Private information is stripped.
it shows C next to Project1 module which means checksum mismatched
Regarding the C for checksum, the help says:
The checksum is missing, not accessible, or equal to zero.
IMHO, for the identification of a PDB, the timestamp is reliable enough, a checksum is not needed. You can use chkmatch to check if your executable matches your symbols.
I get the C warning for my C# programs in Debug and Release build, but I don't have problems.
In the comments you say:
I don't have even f:\dd folder on my system.
This is probably generated by the linker. You use static linking and this embeds some C++ runtime stuff in your executable where the source was compiled by Microsoft.
And someone else says:
It's loading the Project1 symbols from an unusual directory,
That's true, but the symbols of your application could be stored in the symbol store, depending on the symbol path configuration.
See How to set up symbols in WinDbg. In your case it should be
.sympath C:\path\to\your\symbols
.symfix+ C:\microsoft\symbols
.reload
why can't windbg not able to find things
What are you expecting to find?
and is not producing meaningful results?
Which part of the output is not meaningful to you?
Related
The native OCaml compiler exposes options that control whether debug information is emitted. For instance -g controls whether to record information needed to reconstruct exception backtraces. Is there an option to emit the debug information that would be needed for gdb to associate breakpoints with source information like file name and line number?
I don't think OCaml is, at present, a fully supported language for gdb and it isn't possible to pretty-print values or evaluate OCaml expressions. That is okay, I'm just wondering how to configure the ocamlopt compiler or gdb in such a way that gdb can find the source file. Ideally I'd like to be able to see both the OCaml sources and the C source files that implement OCaml runtime when they are present (i.e. when building a compiler by hand rather than through OPAM).
For instance,
(* hello.ml *)
let main () =
Printf.printf "hi there\n%!";;
let () = main ()
compiled using corebuild hello.native, produces a symlink to an executable, hello.native.
and then, when starting gdb:
(gdb) file hello.native
Reading symbols from hello.native...done.
(gdb) start
Temporary breakpoint 1 at 0x405580: file main.c, line 32.
Starting program: /home/g/ws/tmp/ocaml/hello/hello.native
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, main (argc=0x1, argv=0x7fffffffdaf8) at main.c:32
32 main.c: No such file or directory.
We can see that it was unable to determine where the file is.
When you hit C-x a and switch gdb to tui mode, then the message [ No Source Available ] is visible in the top pane.
Use the dir directive in gdb to point it to the place where is the source code of the OCaml runtime, e.g.,
(gdb) dir ~/warehouse/ocaml/byterun/
Source directories searched: /home/ivg/warehouse/ocaml/byterun:$cdir:$cwd
(gdb) l
27 #endif
28
29 CAMLextern void caml_main (char_os **);
30
31 #ifdef _WIN32
32 CAMLextern void caml_expand_command_line (int *, wchar_t ***);
33
34 int wmain(int argc, wchar_t **argv)
35 #else
36 int main(int argc, char **argv)
Few more tips. You can link your program with the debugging runtime, e.g.,
ocamlopt -runtime-variant x -g hello.ml -o hello
It won't have the source code embedded though.
Also, OCaml has quite a good support for gdb, you can step, backtrace, and even observe the source code. The only problem is that names are usually mangled, so it is hard to set up a breakpoint. However, you can use objdump to reverse engineer your file. It is easy if it is built with the -g option:
$ objdump -S hello | grep hello.ml -A 10
(* hello.ml *)
let main () =
404a70: 48 8d 1d 81 a6 24 00 lea 0x24a681(%rip),%rbx # 64f0f8 <camlHello__5>
404a77: 48 8d 05 da b3 24 00 lea 0x24b3da(%rip),%rax # 64fe58 <camlPervasives>
Printf.printf "hi there\n%!";;
404a7e: 48 8b 80 d0 00 00 00 mov 0xd0(%rax),%rax
404a85: e9 66 ae 01 00 jmpq 41f8f0 <camlPrintf__fprintf_1294>
404a8a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
0000000000404a90 <camlHello__entry>:
I got the error when I tried to analyze my Dump Crash File using WinDbg. I corrected my source path and symbol path when I analyzed this issue. I don't know what is the error and why this error happens.
ExceptionAddress: 773e774d (ntdll!_LdrpInitialize+0x00059ba1)
ExceptionCode: c0000135
ExceptionFlags: 00000001
NumberParameters: 0
PROCESS_NAME: asckc.exe
EXCEPTION_CODE: (NTSTATUS) 0xc0000135 - The program can't start because %hs is missing from your computer. Try reinstalling the program to fix this problem.
NTGLOBALFLAG: 0
BUGCHECK_STR: LOADER_INIT_FAILURE_STATUS_DLL_NOT_FOUND
DEFAULT_BUCKET_ID: LOADER_INIT_FAILURE_STATUS_DLL_NOT_FOUND
STACK_TEXT:
00000000 00000000 asckc.exe!Unknown+0x0
STACK_COMMAND: dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ** Pseudo Context ** ; kb
BUCKET_ID: LOADER_INIT_FAILURE_STATUS_DLL_NOT_FOUND_asckc.exe!Unknown
PRIMARY_PROBLEM_CLASS: LOADER_INIT_FAILURE_STATUS_DLL_NOT_FOUND_asckc.exe!Unknown
FAILURE_PROBLEM_CLASS: LOADER_INIT_FAILURE_STATUS_DLL_NOT_FOUND
FAILURE_EXCEPTION_CODE: c0000135
FAILURE_BUCKET_ID: LOADER_INIT_FAILURE_STATUS_DLL_NOT_FOUND_c0000135_asckc.exe!Unknown
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:loader_init_failure_status_dll_not_found_c0000135_asckc.exe!unknown
Could you please help me ?
This error is telling you that there is a DLL that your program (or a DLL loaded by your program) needs to run, but Windows is unable to load it. This can be because something isn't installed right, or you haven't copied all of the DLLs your program needs into the folder you are running from. The error isn't listing the problem DLL so I can't help you any more than that.
You can look for a program called DEPENDS (by Microsoft) that can help track down these sorts of problems.
System : I'm running 32 bit Ubuntu 12.04 on a i32 chipset.
Build Info : I'm using C++ 11 with Qt 4.8.1 and GCC.
Problem : I am developing a project that depends on in-house developed libraries hereafter mentioned to as slug. These libraries are built into .so files via the traditional "cmake ." then "make all" process. After the .so files are generated from cmake, I copy the .so files into a sub-directory of my project so that I can test that they are working before I install them into /usr/lib. Then I provide Qt (in my .pro file) with a absolute path to each library and build my application. My application finds these local libraries and compiles without errors or warnings. However, when I run my application (via command line) I receive the following error:
error while loading shared libraries: libslugSpec.so: wrong ELF class: ELFCLASS64
However, when I build the slug libraries on a 64 bit environment and link to them in a 64 bit environment my application runs perfectly. So, I figured I built the .so files for a 64 bit environment,and proceeded to edit the CMakeLists.txt file used to build the libraries. I add numerous 32 bit compilation and linking flags, shared object module flags, in addition to cuda (which slug relies on) bitness flags . No matter what combination of flags I tried, the libraries generated kept causing the error when running my application executable. So I decided to run the readelf -h command on each shared object file and check to see if they were really 64 bit. I found out that none of them are in fact, all producing logs similar to the following: (output for one of 3 .so files)
readelf -h libslugSpec.so
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x10150
Start of program headers: 52 (bytes into file)
Start of section headers: 511960 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 7
Size of section headers: 40 (bytes)
Number of section headers: 38
Section header string table index: 35
So now I am completely at a loss and can't seem to find an answer anywhere. Any illumination into how this could be happening would be a huge help.
For reference, here are the flags I am providing in the qt .pro file that builds my application:
QMAKE_CXXFLAGS += "-std=gnu++0x"
QT += core gui opengl
TARGET = source
TEMPLATE = app
CONFIG+= wwwidgets
#linux specific settings
unix:!macx{
LIBS += -lGLEW -lGLU /home/alex/Dropbox/brain-viz/source/lib/libslugUtil.so /home/alex/Dropbox/brain-viz/source/lib/libslugSpec.so /home/alex/Dropbox/brain-viz/source/lib/libslugSim.so
}
#windows specific settings
win32{
LIBS += -lglew32 -lwwwidgets4d
}
This error message:
error while loading shared libraries: libslugSpec.so: wrong ELF class: ELFCLASS64
Is not consistent with this output:
readelf -h libslugSpec.so
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Conclusion: you load a different version of libslugSpec.so from the one you ran readelf -h on.
Find out which libslugSpec.so is loaded at runtime by doing this:
LD_DEBUG=files,libs /path/to/your/executable
Then run readelf -h on that library, and confirm that it is in fact ELF64.
Finally replace it with the version you've built (or set LD_LIBRARY_PATH to pick up your version before "system" one), and the problem will be solved.
I developed a tiny MFC application that is going to run on the server 24 hours.
(Windows Server 2008 R2, x64)
I made the app crash on purpose to see if its minidump file is properly created and working, and it works with WinDbg.
Here how I did.
0:000> .symfix c:\symbols
0:000> .sympath+ C:\Projects\*********\x64\Release
0:000> .reload
0:000> !analyze -v
-> Works! I can see full call stack and the line where the error occured!
But, when I do the same thing on my local laptop(Windows XP, x86)
All I can see in call stack text is very basic information as below.
(It doesn't either show what line I should take a look at to debug.)
STACK_TEXT:
0012fd60 0040695c 00000004 dd0fbe7e 00d67d10 **************!CWnd::RunModalLoop+0xf7
0012fdac 004010e0 dd0fbcce 0056bae8 0056bae8 **************!CDialog::DoModal+0x130
0012ff1c 0050e492 00380032 00000000 7ffde000 **************!**************::InitInstance+0xa0
0012ff30 004f7bd7 00400000 00000000 00020934 **************!AfxWinMain+0x48
0012ffc0 7c7e7077 00380032 002d0033 7ffde000 **************!__tmainCRTStartup+0x11a
0012fff0 00000000 004f7c2a 00000000 00000000 kernel32!BaseProcessStart+0x23
-> Meaningless information in this case b/c the error occurs in OnBnClicked function.
I spent several hours googling, but feel lost looking for the answer to this.
Why doesn't it work ONLY on my laptop pc?
What should I check? What am I missing? Any idea would be very appreciated.
Thanks in advance.
You will need the same pdbs without private symbols removed accessible from your laptop in order to get sensible call stacks with correct source line information, also I notice you seem to have cached some symbols to c:\symbols are these the same and also resolve the windows symbols?
Check your visual c++ settings to make sure that you are not stripping private symbols from the pdbs, it will most likely warn you when you try to set breakpoints, search symbols or perform a crash analysis by stating that it was unable to verify the checksum or similar message.
I also notice you are running your app on a 64 bit server and then on a 32 bit laptop, are you running the correct version of WinDbg is my next question, there are 32 and 64 bit versions.
Also what version of windbg are you using? There are often bugs with various versions so you may want to check you are running the same version on your laptop as on your server.
I was curious about .obj files: I pretty much don't know what they are (or what they contain), so I opened them with Vim text editor and what I found inside was an Alien like language...
Is there any way to understand what they represent and what is their content
Also, for what are they being used ?
Thanks.
Sure.
But every different platform has a different object format. On Windows, you could use a tool like dumpbin (dumpbin comes with Visual Studio). On Linux, you could use "dumpobj", or disassemble the program.
Here's a good link for Linux:
http://www.linuxjournal.com/article/1060
PS:
objdump also lets you disassemble the object. Like you used to be able to do with "debug" on DOS PCs...
The .obj files used by link.exe has MS COFF format.
You can find "Microsoft PE and COFF Specification" here, and parse .obj file according to it.
Or, you can use existing tool like dumpbin.
The readelf tool is good at showing you some details on the data:
$ readelf -a /usr/bin/readelf
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
...
Some of its abilities to inspect specific sections of the executable can come in handy too:
$ readelf -p .rodata /usr/bin/readelf | more
String dump of section '.rodata':
[ 4] R_IA64_IMM14
[ 11] R_IA64_NONE
...
[ 1f58] Personality routine:
[ 1f70] __gcc_personality_v0
[ 1f85] __gxx_personality_v0
[ 1f9a] __gcj_personality_v0
[ 1faf] __gnu_objc_personality_v0
...
Actually disassembling the code is a bit of a stretch; if you compile your code with -g for debugging symbols, you can use readelf --debug-dump to read the program source, type information, etc.