hi i have attached crash dump for an exe and symbols also.but i am getting this error:
Unable to verify checksum for abc.exe.
What would be the reason for this?
Unable to verify checksum is emitted when the checksum in the PE header isn't verifiable.
This can happen if the exe in question was compiled and linked without using /RELEASE linker option.
Normal project based compile linker sets this option. nmake or batch file based compilation can omit this switch and can lead to this output.
A simple hello world compiled and linked with and without /RELEASE linker option (PDB not generated for simpilicity and diffed to show the difference in timestamp and checksum). Loaded in WinDbg and checksum warning is generated only for the exe with no checksum in PE header.
simple hello world.cpp contents
testrelease:\>dir /b & type testrelease.cpp
testrelease.cpp
#include <stdio.h>
int main (void) {
printf("hello my relase\n");
return 0;
}
compiling without /RELEASE
testrelease:\>cl /nologo testrelease.cpp
testrelease.cpp
renaming the exe and compiling the same source with with /RELEASE
testrelease:\>ren testrelease.exe testrelease_norel.exe
testrelease:\>cl /nologo testrelease.cpp /link /release
testrelease.cpp
comparing both exes
testrelease:\>fc /b testrelease.exe testrelease_norel.exe
Comparing files testrelease.exe and TESTRELEASE_NOREL.EXE
000000E0: D6 CE
00000130: A3 00
00000131: 95 00
00000132: 01 00
analysing output of the comparison
testrelease:\>xxd -s +0x3c -l 1 testrelease.exe
000003c: d8 .
testrelease:\>xxd -s +0x3c -l 1 testrelease_norel.exe
000003c: d8 .
testrelease:\>echo d8 = NT_HEADER so e0 = TimeDateStamp and 130 = CheckSum
d8 = NT_HEADER so e0 = TimeDateStamp and 130 = CheckSum
loading both exes in windbg warning generated for only one exe without checksum
testrelease:\>cdb -c ".reload /f ; q" testrelease.exe
.*** ERROR: Module load completed but symbols could not be loaded for image00400
testrelease:\>cdb -c ".reload /f ; q" testrelease_norel.exe
.*** WARNING: Unable to verify checksum for image00400000
*** ERROR: Module load completed but symbols could not be loaded for image004000
no symbol header available error means the exe was compiled without debug information.
You can't do much about it unless you have a lot of expertise in recreating debug information from scratch.
Both the executables that are compiled above will generate the error because iIhave intentionally not created the debug information.
DBGHELP: image00400000 missing debug info. Searching for pdb anyway
DBGHELP: Can't use symbol server for image00400000.pdb - no header information available
Related
Analyzing a crash dump, WinDbg says my symbols (PDB file) does not match the module. The symbols are the ones generated when the DLL was compiled. The only thing that I can imagine would cause a mismatch is that the DLL was signed.
I'm using !chksym to validate symbols:
!chksym libcef.dll D:\sym\libcef.dll.pdb
libcef.dll
Timestamp: 5BB3D477
SizeOfImage: 626D000
pdb: F:\src\out\libcef.dll.pdb
pdb sig: B0065D83-113F-63BE-53BC-AEF07EC816B4
age: 1
libcef.dll.pdb
pdb sig: 9BA88A40-D168-44F2-44C1-DD2D73A38B38
age: 1
sig MISMATCH: libcef.dll.pdb and libcef.dll
Code signing an executable or DLL does not affect the debug header of the executable. Thus, it will still match the PDB.
...\SigningPdb\bin\Release>symchk signed.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
...\SigningPdb\bin\Release>symchk unsigned.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
And
...\SigningPdb\bin\Release>ChkMatch.exe -c signed.exe SigningPdb.pdb
ChkMatch - version 1.0
Copyright (C) 2004 Oleg Starodumov
http://www.debuginfo.com/
Executable: signed.exe
Debug info file: SigningPdb.pdb
Executable:
TimeDateStamp: bc78c18e
Debug info: 2 ( CodeView )
TimeStamp: a7b373e5 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 97 RVA: 000026a0 FileOffset: 000008a0
CodeView format: RSDS
Signature: {b8ed520c-cdfc-486b-8e1a-7c0752a2a41f} Age: 1
PdbFile: ...\Release\SigningPdb.pdb
Debug info: 16 ( Unknown )
TimeStamp: 00000000 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 0 RVA: 00000000 FileOffset: 00000000
Debug information file:
Format: PDB 7.00
Signature: {b8ed520c-cdfc-486b-8e1a-7c0752a2a41f} Age: 1
Result: Matched
The timestamp is in the COFF header. That header is only 24 bytes in size and will not change during code signing.
Most changes will happen in a new section for certificates. This section, however, will also be ignored during code signing. Otherwise, a second signature would destroy the first signature. (BTW: this section has been used to transport malicious code inside a signed executable)
Of course, the "usual" checksums, which do not consider the EXE/DLL file structure, will report a different checksum.
What may have happened to your DLL or EXE?
you have accidentally rebuilt it, so the time stamp of your DLL does not match the PDB any more
you are using aspect oriented programming (AOP) in .NET and there is some code weaving happening after a rebuild. These tools might not be able to rebuild the PDB after weaving, so the PDB mismatch is already there before the DLL is code signed.
I'm doing crash analysis on some software,and I'm sure there is no pdb file I can get for the sth.exe,but when sth.exe crashs,every time windbg will search a lot of paths and symbol servers.Even when I cut off the vm's network connection,it still pinned for a while to search the sth.exe's pdb.And this leads to a failure in my auto analysis.Is there a way to tell windbg sth.exe has no pdb,please don't waste time to search it?
create a file named symsrv.ini
in the folder where windbg is installed
the directory in this sample is e:\ewdk\program files\windows kits\10\Debuggers\x86
create an exclusion section in the file
and add all the unknown pdb's list into it
symsrv wont go searching for them
:\>ls -l symsrv.ini
-rw-rw-rw- 1 HP 0 259 2016-08-18 17:43 symsrv.ini
:\>file symsrv.ini
symsrv.ini; ASCII text, with CRLF line terminators
:\>cat symsrv.ini
[exclusions]
livekdD.sys
vmm.pdb
livekdD.pdb
vmci.pdb
vsock.pdb
clwvd.pdb
spldr.pdb
vmkbd.pdb
vmnetsrv.pdb
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
:\>livekd
LiveKd v5.40 - Execute kd/windbg on a live system
Sysinternals - www.sysinternals.com
!sym noisy
noisy mode - symbol prompts off
kd> .reload /f
SYMSRV: vmci.pdb is in the file exclusion list
DBGHELP: d:\build\ob\bora-1141980\bora-vmsoft\build\release\crosstalk\windows\wi
n2k\i386\vmci.pdb - file not found
*** ERROR: Symbol file could not be found. Defaulted to export symbols for vmci.sys -
DBGHELP: vmci - export symbols
SYMSRV: vsock.pdb is in the file exclusion list
DBGHELP: d:\build\ob\bora-1253991\bora-vmsoft\build\release\vsock\windows\win2k\
i386\vsock.pdb - file not found
*** ERROR: Symbol file could not be found. Defaulted to export symbols for vsock.sys -
DBGHELP: vsock - export symbols
SYMSRV: vmm.pdb is in the file exclusion list
DBGHELP: m:\src\built\vs2005.sp2\vssp2\usa\ent_volume\i386\sym\sys\vmm.pdb - fil
e not found
*** ERROR: Module load completed but symbols could not be loaded for vmm.sys
DBGHELP: vmm - no symbols loaded
************* Symbol Loading Error Summary **************
Module name Error
vmci The system cannot find the file specified : srv*e:\symbols*
http://msdl.microsoft.com/download/symbols The SYMSRV client
failed to find a file in the UNC store, or there is an invalid
UNC store (an invalid path or thepingme.txt file is not present
in the root directory), or the fileis present
in the symbol server exclusion list.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
answer to comment
well for a start there is a setting up exclusion list topic in windbg help
this topic alludes to this file (file is alluded in respect to using the symproxy and is supposed to be created at %windowsdir\system32\inetsrv\" and doesnt work for symsrv.dll (the registry key also doesnt seem to work )
https://msdn.microsoft.com/en-us/library/windows/hardware/ff556870(v=vs.85).aspx
for me i saw in procmon a failure with NameNotFound error in fastio path in windbg installation directory
so on a hunch i moved the file from above mentioned path to windbg installation directory
and things seemed to work correctly that was very long back
but subsequently i've seen post from jason shay (MSFT) in osr windbg lists stating this feature was pushed in windbg 6.4.4 beta
http://www.osronline.com/showthread.cfm?link=68916
so there isn't any common sense missing just that the corner cases are always difficult to find
I'm debugging a piece of code and I got it to break at an exception. I have the relevant source and symbol paths set up, but when I use ls, it doesn't show or list the current source file, even when it highlights the line in the open source file I'm interested in when I select the correct stack frame.
Why is that? What am I not understanding? What is meant by 'current source file'?
When you are on an address where source file is not available (like _dbgbreakpoint on ntdll) issuing ls will emit the message "No current source file":
0:000> ln #eip
(7c90120e) ntdll!DbgBreakPoint | (7c901212) ntdll!DbgUserBreakPoint
Exact matches:
ntdll!DbgBreakPoint = <no type information>
0:000> ls
No current source file
ls by itself requires a preloaded source file using lsf or you need to set the .srcpath.
This loaded source file remains loaded until you remove it or another source file is loaded automatically by an event (i.e. if you do .restart and break on _dbgbreak and do a ls, it will show the stale source file that was loaded with lsf earlier):
0:000> .restart
ntdll!DbgBreakPoint:
7c90120e cc int 3
0:000> ls
77: PAttributeHeader psecondheader = NULL ;
78: PAttributeHeader pthirdheader = NULL;
79: PFileInfoAttributeRecord pfinforecord = NULL;
80:
81: memset(&dump,0,sizeof(dump));
82: fopen_s( &fp,"\\\\.\\PHYSICALDRIVE0", "rb" );
Using lsa . (notice the .) instead of ls, it loads the source for the current address.
The current line is denoted by > in the paste below .
Notice ls fails due to no pre loaded source file whereas lsa . gives you the source line.
0:000> g wmain
00401000 55 push ebp
0:000> ls
No current source file
0:000> lsa .
67: }FileInfoAttributeRecord,*PFileInfoAttributeRecord;
68:
69:
70: int _tmain(int argc, _TCHAR* argv[])
> 71: {
We are using cdb (command line version of winDBG) to resolve a cab.
For getting the output in a file we are using the -logo output to specify the output file.
For a certain cab we are getting "CvRegToMachine(x86) conversion failure for 0x7536" more than a million times.
Basically we get a huge resolved code log, nearly 1GB, and all of it filled with the above string on each line.
We are using the following cdb command
cdb -z "abc.cab" -y "SymbolsPath" -G -logo "outputfile" -lines -c ".kframes 100;!analyze -v;!load msec.dll;!exploitable -v;vertarget;lmv;q"
Does anyone have any clue about what could be wrong here?
you cannot use -c and -G at the same time -c needs the first break to read the initial
command and act upon it if you need to run the code use g; at the end of -c commands
also many times -c commands need to be provided first and the debugee needs
to be at the end of commandline
cdb -c "<some cmd;someother cmd;g>" -z foo.cab
.load not !load should be used to load third party extensions
the string emitted "CvReg.........." seems to be related to Either SYMFLAG_NULL or SYMFLAG_REGISTER in the Flags member of SYMBOLINFO Struct .
a sample trial didnt cross that code path in my machine so either the corrupt dmp or more information regarding the dmp file may be needed to find the reason for the spew
creating dump
C:\>dir /b *.cab
File Not Found
C:\>cdb -c ".dump /ma /b foo.cab;q" calc | grep -i -E "dmp|dump|wr"
0:000> cdb: Reading initial command '.dump /ma /b foo.cab;q'
Creating C:\DOCUME~1\Admin\LOCALS~1\Temp\foo.cab.dmp - mini user dump
Dump successfully written
Adding C:\DOCUME~1\Admin\LOCALS~1\Temp\foo.cab.dmp - added
Wrote foo.cab
C:\>dir /b *.cab
foo.cab
**loading dump as debugees(cdb) debuggee (foo.cab) and looking around **
C:\>cdb cdb -z foo.cab
0:000> s -u dbgeng l?39b000 "CvReg"
020341f8 0043 0076 0052 0065 0067 0054 006f 004d C.v.R.e.g.T.o.M.
0:000> # *(*20341f8 dbgeng l?39b000
dbgeng!MachineInfo::CvRegToMachine+0xfe:
021bf8ae 68f8410302 push offset dbgeng!`string' (020341f8)
0:000> # call*dbgeng!MachineInfo::CvRegToMachine dbgeng l?39b000
dbgeng!ImageInfo::CvRegToMachine+0x22:
021b62f2 e8b9940000 call dbgeng!MachineInfo::CvRegToMachine (021bf7b0)
0:000> # call*CvRegToMachine dbgeng l?39b000
dbgeng!ImageInfo::CvRegToMachine+0x22:
021b62f2 e8b9940000 call dbgeng!MachineInfo::CvRegToMachine (021bf7b0)
dbgeng!TypeInfoValueFromSymInfo+0x4b:
022541ab e82021f6ff call dbgeng!ImageInfo::CvRegToMachine (021b62d0)
dbgeng!TypedData::SetToSymbol+0x25f:
02285edf e8ec03f3ff call dbgeng!ImageInfo::CvRegToMachine (021b62d0)
dbgeng!TypedData::SetToSymbol+0x2da:
02285f5a e87103f3ff call dbgeng!ImageInfo::CvRegToMachine (021b62d0)
0:000> ln 0x21bf8ae
(021bf7b0) dbgeng!MachineInfo::CvRegToMachine+0xfe | (021bf8d0) dbgeng!Ma
chineInfo::GetContextState
doing and uf on this function yields the check where SymbolInfo->Flags is
checked and decided my sample dump above doesnt enter the path
Has anyone encountered the error below when compiling omniORB_4.1.6 64-bit for windows?
'RegQueryValueEx failed - error 109'
I followed the procedure in the readme.win32 and I get linking errors in the omniDyamic, codesets etc.. So someone suggested to rebuild the omniorb_root/src/tools/win32 and copy it in bin/x86_win32/. That's what I did and when I recompile the whole omniORB, the error is as below:
../../../../bin/x86_win32/omkdepend -D__cplusplus -D_MSC_VER -DIDLMODULE_VERSION
="0x2630" -DMSDOS -DOMNIIDL_EXECUTABLE -Ic:/python27/include -Ic:/python27/PC -I
c:/python27/include/python2.7 -DPYTHON_INCLUDE=<Python.h> -I. -I. -I../../../../
include -D__WIN32__ -D_WIN32_WINNT=0x0501 -D__x86__ -D__NT__ -D__OSVERSION__=4 -
D_CRT_SECURE_NO_DEPRECATE=1 idlc.cc idlpython.cc idlfixed.cc idlconfig.cc idldum
p.cc idlvalidate.cc idlast.cc idlexpr.cc idlscope.cc idlrepoId.cc idltype.cc idl
util.cc idlerr.cc lex.yy.cc y.tab.cc
RegQueryValueEx failed - error 109
-----------------------------------------------------------------------------------------------
make[4]: Entering directory `/cygdrive/c/Software/COTS/omniORB/omniORB_4.1.6/src
/tool/omniidl/cxx/cccp'
../../../../../bin/x86_win32/clwrapper -gnuwin32 -c -O2 -MD -GS -GR -Zi -nologo
-DHAVE_CONFIG_H -I. -I. -I. -I../../../../../include -D__WIN32__ -D_WIN32_WINNT=
0x0501 -D__x86__ -D__NT__ -D__OSVERSION__=4 -D_CRT_SECURE_NO_DEPRECATE=1 -Focexp
.o cexp.c
RegQueryValueEx failed - error 109
I'm going to answer my own question because it seems nobody has encountered this problem, and the mailing list is so quiet.
Someone suggested to me to recompile the src\tools\win32. So that's what I did and I copied the .exe files generated to bin\x86_win32.
I then compiled all the omniORB and get the RegQueryValueEx error.
The reason for this is when you check the src\tools\win32\bccwrapper.c in the void GetMounts(void) function,
it looks for this path in the registry:
Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\%02X.
When I checked that using regedit, I noticed that in the mounts->00, 01, 02, 03 etc.. keys, there are no 'unix' and 'native' string values inside those keys.
So I decided to delete all the keys and retained just the 00 and added a 'unix' and 'native' string value.
After which, I recompiled the src\tools\win32 and copied over the created .exe files to bin\x86_win32 and finally when I recompiled all the omniOrb, it started compiling (need to copy the ssl libs too) and finished successfully.
I really don't even know how the following got into my registry:
Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\%02X.
Best regards,
Mark
I spent quite some time trying to compile OmniORB on windows 10 with visual studio 2017.
Assuming Cygwin64 was installed in directory
c:\software\cygwin64
, the compilation of OmniORB is quite straightforward:
open a command terminal (cmd)
in that terminal, setup the Visual environment:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x64
then, append the PATH (yes append and not prepend):
set PATH=%PATH%;c:\software\cygwin64\bin
then, in file config\config.mk, uncomment this line
platform = x86_win32_vs_15
in file platforms\x86_win32_vs_15, set PYTHON to target the python executable, in my case Python 3.6.5
PYTHON = /cygdrive/c/software/Python/python
finally start the compilation with make:
make export
Hope this helps.