WARNING: Unable to verify checksum - managed code

[Asher F.]

Hello,
I am tring to take a process dump in order to debug a memory leak.
I am using ADPlus.vbs and the DNHang.xml configuration file (based on John
Robbins article in MSDN magazine
http://msdn.microsoft.com/msdnmag/issues/05/03/Bugslayer, the only change I
made to the file is in the .load sos call which I changed to load the SOS.dll
if .NET 2.0 framework)

One of the things the dump does is to call the !dumpheap -stat command,
however this command fails.
For all my DLLs which are part of process and are compiled in debug mode
with PDB files generated
I get the '*** WARNING: Unable to verify checksum for <dll name here>'
message.

As far as I can tell the symbols are ok since if I use VS 2005 to attach to
the process, all the symbols are loaded properly and I can debug the
application.

What is the cause and meaning of this error? What should I do to rectify it?
Thanks for the help.

I saw a couple of posts about this issue on this newsgroup, however, it
looks like
it related to native/unmanaged code. I use C# under .NET 2.0 and the process
is a Windows Application).

[Jeffrey Tan[MSFT]]

Hi Asher,

Is your dump file a minidump or full dump? Have you included the binary
images in the dump file?(default minidump will not include binary images)

If you input "lm" command in the windbg, can you verify if the symbols are
loaded?

Further, you may use "!lmi [module_name]" to check if your image module has
the correct checksum field set. Also, you may use "!dh [module_name]" to
examine the PE module header.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Asher F.]

Hi Jeffrey,
Thank you for your help.
I am working with WinDbg v6.6.7.5.
(I am doing this on a small test app since it is easly reproducable on this
app.)

I started WinDbg, set thhe symbol path to the path app is located (where
Visual Studio puts it, in the bin\debug folder).
Then I and attached to the .NET process.

then I loaded SOS (.load
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\SOS.dll;)

I ran all the commands as you suggests the output is in the end of this
message (lm, lmi, dh, dh -stat).
however, it looks like the checksum (!dh [module name] command) is zero.
why is that ? what is wrong ?


----------------------- commands output -------------------------------
0:003> lm
start end module name
00400000 00408000 ConsoleDebugTest (deferred)
5d090000 5d12a000 comctl32_5d090000 (deferred)
629c0000 629c9000 LPK (deferred)
74d90000 74dfb000 USP10 (deferred)
76390000 763ad000 IMM32 (deferred)
773d0000 774d3000 comctl32 (deferred)
774e0000 7761d000 ole32 (deferred)
77c10000 77c68000 msvcrt (deferred)
77dd0000 77e6b000 ADVAPI32 (deferred)
77e70000 77f01000 RPCRT4 (deferred)
77f10000 77f57000 GDI32 (deferred)
77f60000 77fd6000 SHLWAPI (deferred)
78130000 781cb000 MSVCR80 (deferred)
79000000 79045000 mscoree (deferred)
79060000 790b3000 mscorjit (deferred)
790c0000 79b90000 mscorlib_ni (deferred)
79e70000 7a3d6000 mscorwks (deferred)
7c800000 7c8f5000 KERNEL32 (deferred)
7c900000 7c9b0000 ntdll (export symbols)
C:\WINDOWS\system32\ntdll.dll
7c9c0000 7d1d6000 shell32 (deferred)
7e410000 7e4a1000 USER32 (deferred)

---------------
0:003> !lmi ConsoleDebugTest
Loaded Module Info: [consoledebugtest]
Module: ConsoleDebugTest
Base Address: 00400000
Image Name: C:\stuff\Visual Studio
Projects\ConsoleDebugTest\bin\Debug\ConsoleDebugTest.exe
Machine Type: 332 (I386)
Time Stamp: 4729b62d Thu Nov 01 13:19:09 2007
Size: 8000
CheckSum: 0
Characteristics: 10e
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 68, 27b4, 17b4 RSDS - GUID:
{3EA45616-C090-46BB-BD33-F99323 C4F8B}
Age: 1, Pdb: C:\stuff\Visual Studio
Projects\ConsoleDebugTest\obj\Debug\ConsoleDebugTest.pdb
Symbol Type: DEFERRED - No error - symbol load deferred
Load Report: no symbols loaded

---------------
0:003> !dh ConsoleDebugTest

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (i386)
3 number of sections
4729B62D time date stamp Thu Nov 01 13:19:09 2007

0 file pointer to symbol table
0 number of symbols
E0 size of optional header
10E characteristics
Executable
Line numbers stripped
Symbols stripped
32 bit word machine

OPTIONAL HEADER VALUES
10B magic #
8.00 linker version
1000 size of code
2000 size of initialized data
0 size of uninitialized data
78C04010 address of entry point
2000 base of code
----- new -----
00400000 image base
2000 section alignment
1000 file alignment
3 subsystem (Windows CUI)
4.00 operating system version
0.00 image version
4.00 subsystem version
8000 size of image
1000 size of headers
0 checksum
00100000 size of stack reserve
00001000 size of stack commit
00100000 size of heap reserve
00001000 size of heap commit
0 [ 0] address [size] of Export Directory
281C [ 4F] address [size] of Import Directory
4000 [ 3A8] address [size] of Resource Directory
0 [ 0] address [size] of Exception Directory
0 [ 0] address [size] of Security Directory
6000 [ C] address [size] of Base Relocation Directory
2798 [ 1C] address [size] of Debug Directory
0 [ 0] address [size] of Description Directory
0 [ 0] address [size] of Special Directory
0 [ 0] address [size] of Thread Storage Directory
0 [ 0] address [size] of Load Configuration Directory
0 [ 0] address [size] of Bound Import Directory
2000 [ 8] address [size] of Import Address Table Directory
0 [ 0] address [size] of Delay Import Directory
2008 [ 48] address [size] of COR20 Header Directory
0 [ 0] address [size] of Reserved Directory


SECTION HEADER #1
.text name
874 virtual size
2000 virtual address
1000 size of raw data
1000 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
60000020 flags
Code
(no align specified)
Execute Read


Debug Directories(1)
Type Size Address Pointer
cv 68 27b4 17b4 Format: RSDS, guid, 1, C:\stuff\Visual
Studio Projects\ConsoleDebugTest\obj\Debug\ConsoleDebugTest.pdb

SECTION HEADER #2
.rsrc name
3A8 virtual size
4000 virtual address
1000 size of raw data
2000 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40000040 flags
Initialized Data
(no align specified)
Read Only

SECTION HEADER #3
.reloc name
C virtual size
6000 virtual address
1000 size of raw data
3000 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42000040 flags
Initialized Data
Discardable
(no align specified)
Read Only
---------------
0:003> !dh -stat
*** WARNING: Unable to verify checksum for C:\stuff\Visual Studio
Projects\ConsoleDebugTest\bin\Debug\ConsoleDebugTest.exe
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\comctl32.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\LPK.DLL -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\USP10.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\IMM32.DLL -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\ole32.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\msvcrt.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\ADVAPI32.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\RPCRT4.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\GDI32.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\SHLWAPI.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\mscoree.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorjit.dll -
*** WARNING: Unable to verify checksum for
C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\mscorlib\fe3022d80b5605cfa289f5092b97e58c\mscorlib.ni.dll
*** ERROR: Module load completed but symbols could not be loaded for
C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\mscorlib\fe3022d80b5605cfa289f5092b97e58c\mscorlib.ni.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\KERNEL32.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\shell32.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\USER32.dll -
--
Asher.

Post by Jeffrey Tan[MSFT]
Hi Asher,
Is your dump file a minidump or full dump? Have you included the binary
images in the dump file?(default minidump will not include binary images)
If you input "lm" command in the windbg, can you verify if the symbols are
loaded?
Further, you may use "!lmi [module_name]" to check if your image module has
the correct checksum field set. Also, you may use "!dh [module_name]" to
examine the PE module header.
Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights

[Jeffrey Tan[MSFT]]

Hi Asher,

Thanks for your feedback.

Oh, yes, as I tested, all the .Net assemblies will have zero checksum
regardless of debug or release build. Even the .Net Framework assemblies
will have zero checksum:

0:006> !lmi System_Windows_Forms_ni
Loaded Module Info: [system_windows_forms_ni]
Module: System.Windows.Forms.ni
Base Address: 7afd0000
Image Name:
C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System.Windows.Forms\75a84726
b593aa72b686b8671027ba3c\System.Windows.Forms.ni.dll
Machine Type: 332 (I386)
Time Stamp: 461ef203 Fri Apr 13 10:59:15 2007
Size: c84000
CheckSum: 0
Characteristics: 210e
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 31, 6c001c, 6be01c RSDS - GUID:
{649C2867-D694-460E-95FC-16384A0D711B}
Age: 1, Pdb: System.Windows.Forms.pdb
Symbol Type: DEFERRED - No error - symbol load deferred
Load Report: no symbols loaded

I am not sure of the reason yet; I would suspect it may has something to do
with JIT. Anyway, I will try to contact CLR team for this issue.

Actually, even the module does not have checksum field, windbg can load
symbol for it without any problem once you configured the symbol server
correctly:
0:007> ld System_Windows_Forms_ni
*** WARNING: Unable to verify checksum for
C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System.Windows.Forms\75a84726
b593aa72b686b8671027ba3c\System.Windows.Forms.ni.dll
Symbols loaded for System_Windows_Forms_ni


Windbg will use the codeview debug record in the PE module file to match
the symbols. That is the output you see in the "!lmi" command:
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 31, 6c001c, 6be01c RSDS - GUID:
{649C2867-D694-460E-95FC-16384A0D711B}
Age: 1, Pdb: System.Windows.Forms.pdb

For more information of how windbg matches symbol for PE module, see the
article below:
"matching debug information"
http://www.debuginfo.com/articles/debuginfomatch.html

Finally, the zero checksum behavior is .Net assembly specific; For
unmanaged PE file, we may add /release option to the link.exe to generate
the checksum:
http://msdn2.microsoft.com/en-us/library/h8ksa72a(VS.71).aspx

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Asher,

Sorry for letting you wait.

I have tried to contact the CLR team for several emails, but did not get a
solid response yet. All .Net Framework assemblies are Ngened, so it is the
author of NGen who believes to not generate checksum for the .Net
assemblies.

Currently, I would recommend you to submit a feedback request in the link
below:
https://connect.microsoft.com/VisualStudio

The .Net team will receieve your request and provide an official response
to you.

Anyway, since windbg will use codeview record to match the symbol files,
the missing of checksum field does no harm to your debugging. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Asher F.]

Hi Jeffrey,
I looked at the commands I run as part of the ADPlus dump I am taking.
apperently the !dh command is not the !dumpheap command (it used to be..)
so when I do a !dumpheap I get what I need.
however, one of the commands I run when I do the dump is the ~*e!clrstack
command to dump the state/stack of all managed threads.
I get the full stack (classes,method names) but I am missing line numbers
(which I get if I throw an exception).
is it due to the symbol loading issue ? If I remeber correctly, the PDB
files are needed to produce line numbers (for exception stack trace) is it
the same of the clrstack command ?
what should I do to get the line numbers in the clrstack command?
--
Asher.

Post by Jeffrey Tan[MSFT]
Hi Asher,
Sorry for letting you wait.
I have tried to contact the CLR team for several emails, but did not get a
solid response yet. All .Net Framework assemblies are Ngened, so it is the
author of NGen who believes to not generate checksum for the .Net
assemblies.
Currently, I would recommend you to submit a feedback request in the link
https://connect.microsoft.com/VisualStudio
The .Net team will receieve your request and provide an official response
to you.
Anyway, since windbg will use codeview record to match the symbol files,
the missing of checksum field does no harm to your debugging. Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights

[Jeffrey Tan[MSFT]]

Hi Asher,

Thanks for your feedback.

#1, yes, I also remember that there is a "!dh" short alias for "!dumpheap"
command in SOS.dll extension. But, the current version seems have got rid
of this alias. I think the reason is that the author of SOS.dll does not
want the user to be confused with "!dh" from SOS.dll and Dbghelp.dll. If
you wanted to confirm if any SOS commands have the alias available, you may
use !sos.help to get all the commands list:
0:004> !sos.help
----------------------------------------------------------------------------
---
SOS is a debugger extension DLL designed to aid in the debugging of managed
programs. Functions are listed by category, then roughly in order of
importance. Shortcut names for popular functions are listed in parenthesis.
Type "!help <functionname>" for detailed info on that function.

Object Inspection Examining code and stacks
----------------------------- -----------------------------
DumpObj (do) Threads
DumpArray (da) CLRStack
DumpStackObjects (dso) IP2MD
DumpHeap U
DumpVC DumpStack
GCRoot EEStack
ObjSize GCInfo
FinalizeQueue EHInfo
PrintException (pe) COMState
TraverseHeap BPMD

Examining CLR data structures Diagnostic Utilities
----------------------------- -----------------------------
DumpDomain VerifyHeap
EEHeap DumpLog
Name2EE FindAppDomain
SyncBlk SaveModule
DumpMT GCHandles
DumpClass GCHandleLeaks
DumpMD VMMap
Token2EE VMStat
EEVersion ProcInfo
DumpModule StopOnException (soe)
ThreadPool MinidumpMode
DumpAssembly
DumpMethodSig Other
DumpRuntimeTypes -----------------------------
DumpSig FAQ
RCWCleanupList
DumpIL

As you can see, there is no "dh" alias for "DumpHeap" now, but there are
still alias do, da, dso etc..

#2, yes, the source code lines are embeded in the PDB symbol files by
compiler/linker. So, you must get symbol loaded to get the source file
lines information. To check this, you may input "lm" command to see if the
modules have correct symbol files loaded. If not, you may enable the
verbose symbol loading with "!sym noisy" command with a ".reload". Then,
windbg will output the details symbol file lookup process, you will
understand why your PDB files are not probed. After this, you may use
".sympath+ [your priviate symbol path]" command to tell the windbg where to
find your specific PDB files.

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.