Why does the checksum fail for pdb files with Windbg?

Question

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?

Answer 1

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

Answer 2

when I run lm Project1.exe, it doesn't understand Project1.exe

The lm Project1.exe command fails for 2 reasons:

1. The module name is Project1 and not Project1.exe
2. 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?