I am learning analysing pe files and I have come to the checksum in the optional headers in executable images and how it is used to check for validation of drivers and system dlls. I checked some windows binaries, and they have some value in the checksum field then I checked executables and dlls I built using visual studio msvc 22 and 19, but all contains zero in the checksum field. I then checked other binaries in software I use on windows, and they seem also to have zero in the checksum field.
I this filed is not set by msvc compiler for new executables or it is specific to Microsoft only programs ?
Related
On my development machine, I have Delphi 10.2 and Firebird 2.5. Database apps that I create in this configuration work correctly.
I copied one program along with its database to another computer running Windows 10. I installed Firebird; I also installed SQL Manager Lite for InterBase/Firebird on this computer, and this program is able to open the database and view the data contained within. But my Delphi program cannot open the database, displaying the error message 'Unable to load dbxfb.dll (error code 193). It may be missing from the system path'.
I have copied dbxfb.dll to every location that I can think of (the same directory as where the program is, the same directory as where the database is, windows\system32, C:\Program Files (x86)\Firebird, and more) but the message stays the same. On my development machine, what I believe to be the path (i.e. system properties\advanced\environment variables) contains only the directory %USERPROFILE%\AppData\Local\Microsoft\WindowsApps. On the other computer, I added C:\Program Files (x86)\Firebird but to no avail.
So where should dbxfb.dll be located, or how do I "tell" my program where to find it?
Edit: Regarding 'bitness', both computers are 64 bit. In the Project Options dialog box in Delphi, there is only the option of 32 bits. I've set the program's compatibility setting to Windows 8, but this made no difference regarding the missing dll.
Further edit: The version that is/was on the target machine is 1,412kb in size and dated 13/11/2015 1:55; this version apparently comes from C:\Program Files (x86)\Embarcadero\Studio\17.0\bin64, so this is definitely the wrong version.
In C:\Program Files (x86)\Embarcadero\Studio\17.0\bin, there is a version that is only 278kb in size, same date but hour 06:55. Copying the smaller file to the target machine and running the program gives now a different error message: i/o error during "#1" operation for file "#2". Error while trying to open file.
https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-
ERROR_BAD_EXE_FORMAT
193 (0xC1)
%1 is not a valid Win32 application.
It is indeed the bitness problem as suggested by Mark.
(Warning: long read. This question references a lof of the other questions about F2051)
We have a folder named PatchLibs in our source tree in which we put modified files of third party sources.
This is in the project search path: ..\Skin;..\PatchLibs
I copied the file dxBar.pas from DevExpress controls into Patchlibs and modified some code in the implementation section only.
Now, when building (with all local .dcu files deleted and a 'Cleanup') I get the infamous:
[dcc32 Fatal Error] F2051 Unit cxBarEditItem was compiled with a different version of dxBar.TdxBarItemControl.GetItem
It doesn't refer to a line of code. I get the message when it starts compiling.
Configuration:
New Delphi and DevExpress versions installed in a new VM; copied the program source tree.
C:\DelphiLibs\DevExpress\VCL\Library\RS27 is in the 32bit library path
That folder contains all the DevExpress dcu's, notably cxBarEditItem.dcu and dxBar.dcu
(So does the $(DXVCL)\Library\RS27\Win64 library path, but this is a Win32 app)
There are no other occurrences of cxBarEditItem.dcu anywhere; dcBar.pas and cxBarEditItem.pas are in c:\DelphiLibs\DevExpress\VCL\ExpressBars\Sources\
(I even scanned the disk for all cx*.* and dx*.* files).
That source folder is also present in the Browsing path ($(DXVCL)\ExpressBars\Sources)
These are just units (no corresponding .dfm files)
There are other modified DevExpress files in Patchlibs that I have no issues with; and there are some more with which I have the same issue (not just dxBar).
Project is set up to place .dcu files next to their .pas sources (Unit Output Directory is blank)
No DevExpress files are part of the project
Other source files in the project have changed
If I pull a copy of cxBarEditItem.pas into Patchlibs, the error only just propagates to another unit (repeatedly).
Despite having read many answers (Notable SO question: Why are my units "compiled with a different version" of my own files?)
I simply do not understand why the error occurs and how to fix it this time.
cxBarEditItem.pas has dxBar in its interface Uses section, and cxBarEditItem is in my Uses clauses, but why would it want to recompile?
I can of course start adding the DevExpress source code directories into the Search Path, but there are a lot of those and this will result in .dcu files in them as well.
I prefer not to do that because it masks the actual problem and this was not necessary in the previous Delphi/DevExpress setup:
32 bits library path in earlier Delphi 10.3:
c:\DelphiLibs\CompanyName
c:\DelphiLibs\CompanyName\TTLib
c:\DelphiLibs\CompanyName\DataFox
C:\DelphiLibs\RBuilder\Source
$(BDSLIB)\$(Platform)\release
$(BDSUSERDIR)\Imports
$(BDS)\Imports
$(BDSCOMMONDIR)\Dcp
$(BDS)\include
c:\delphilibs\multilizer\localizationcomponentsxex_x86\packages\full\bplxe\20.0
C:\DelphiLibs\Multilizer\LocalizationComponentsXEx_x86
c:\delphilibs\pascal script\dcu\d25\win32
C:\DelphiLibs\Pascal Script\Source
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Dcu\D26\Win32
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\DataSnap
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\ZLib
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\Synapse
$(Everwood)\Bin
C:\DelphiLibs\Scalabium\SMExport\Sources
C:\DelphiLibs\Scalabium\SMImport\Sources
C:\DelphiLibs\Cooltray
C:\DelphiLibs\PlusMemo\
C:\Delphilibs\RBuilder\Lib\Win32
C:\DelphiLibs\PlusMemo
C:\DelphiLibs\IPWorks 2020 Delphi Edition\pas
C:\DelphiLibs\IPWorks Auth 2020 Delphi Edition\pas
C:\DelphiLibs\IPWorks Encrypt 2020 Delphi Edition\pas
C:\DelphiLibs\IPWorks SSH 2020 Delphi Edition\pas
C:\DelphiLibs\IPWorks ZIP 2020 Delphi Edition\pas
C:\DelphiLibs\VirtualUI\dev\Delphi
c:\DelphiLibs\CEF4Delphi-master\source\
$(DXVCL)\Library\RS26
32 bits library path in Delphi 10.4:
c:\DelphiLibs\CompanyName
c:\DelphiLibs\CompanyName\TTLib
c:\DelphiLibs\CompanyName\DataFox
C:\DelphiLibs\RBuilder\Source
c:\program files (x86)\embarcadero\studio\21.0\lib\Win32\release
C:\Users\Jan\Documents\Embarcadero\Studio\21.0\Imports
c:\program files (x86)\embarcadero\studio\21.0\Imports
C:\Users\Public\Documents\Embarcadero\Studio\21.0\Dcp
c:\program files (x86)\embarcadero\studio\21.0\include
c:\delphilibs\plusmemo
C:\DelphiLibs\RBuilder\Lib\Win32
C:\DelphiLibs\Multilizer\LocalizationComponentsXEx_x86
C:\DelphiLibs\PlusMemo
C:\DelphiLibs\Pascal Script\Source
C:\DelphiLibs\Scalabium\SMExport\Sources
C:\DelphiLibs\Scalabium\SMImport\Sources
C:\DelphiLibs\Cooltray
C:\DelphiLibs\VirtualUI\dev\Delphi
C:\DelphiLibs\nSoftware\IPWorks 2020 Delphi Edition\pas
C:\DelphiLibs\nSoftware\IPWorks Auth 2020 Delphi Edition\pas
C:\DelphiLibs\nSoftware\IPWorks SSH 2020 Delphi Edition\pas
C:\DelphiLibs\nSoftware\IPWorks ZIP 2020 Delphi Edition\pas
C:\DelphiLibs\nSoftware\IPWorks Encrypt 2020 Delphi Edition\pas
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Dcu\D27\Win32
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\DataSnap
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\Grijjy
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\Synapse
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\ZLib
C:\Program Files (x86)\RemObjects Software\Everwood\Bin
C:\DelphiLibs\SQLDirect\Source
C:\DelphiLibs\CEF4Delphi-master\source
C:\DelphiLibs\DevExpress\VCL\Library\RS27
Moving that last one up or down or changing it to $(DXVCL)\Library\RS27 did not help
Those 5 Embarcadero lines look weird (see this SO question,
I replaced them with their old counterparts (and reported to Embarcadero); no change in the issue.
Additional research/failed attempt
Ian Boyd had a very a similar problem way down in 2014
F2051: Unit %s was compiled with a different version of %s
Suggestions there were RTTI settings or compiler options.
Based on David's answer there, I decided to give that a try.
My situation was slightly different: I had to try to find out what compiler settings were used when building the DevEx code and insert those into the top of my modified dxBar.pas.
I noticed that there are two .dproj files in Packages subfolders in the DevExpress installation: cxLibraryRS27.dproj and dxBarRS27.dproj (requiring cxLibraryRS27 BTW)
By setting all compiler options in a test project to non-defaults and comparing that .dproj to one with all the defaults I was able to understand (most of) the relation between UI option settings and the .dproj contents.
I then compared their cxLibraryRS27.dproj settings against those from our project and found the following differences (irrelevant lines removed):
They had this extra:
<PropertyGroup Condition="'$(Base)'!=''">
<DCC_E>false</DCC_E> No idea what these are...
<DCC_F>false</DCC_F>
<DCC_K>false</DCC_K>
<DCC_N>false</DCC_N>
<DCC_S>false</DCC_S>
<DCC_DebugInformation>0</DCC_DebugInformation>
<DCC_LocalDebugSymbols>false</DCC_LocalDebugSymbols>
<DCC_AssertionsAtRuntime>false</DCC_AssertionsAtRuntime>
<DCC_SymbolReferenceInfo>0</DCC_SymbolReferenceInfo>
We had this extra:
<PropertyGroup Condition="'$(Cfg_1)'!=''">
(this is the one with <DCC_Define>RELEASE;$(DCC_Define)</DCC_Define>)
<DCC_IntegerOverflowCheck>True</DCC_IntegerOverflowCheck>
<DCC_RangeChecking>True</DCC_RangeChecking>
<DCC_SYMBOL_DEPRECATED>False</DCC_SYMBOL_DEPRECATED>
<DCC_SYMBOL_LIBRARY>False</DCC_SYMBOL_LIBRARY>
<DCC_SYMBOL_PLATFORM>False</DCC_SYMBOL_PLATFORM>
<DCC_UNIT_LIBRARY>False</DCC_UNIT_LIBRARY>
<DCC_UNIT_PLATFORM>False</DCC_UNIT_PLATFORM>
<DCC_UNIT_DEPRECATED>False</DCC_UNIT_DEPRECATED>
<PropertyGroup Condition="'$(Cfg_1_Win32)'!=''">
<DCC_COMBINING_SIGNED_UNSIGNED>false</DCC_COMBINING_SIGNED_UNSIGNED>
<DCC_COMPARING_SIGNED_UNSIGNED>false</DCC_COMPARING_SIGNED_UNSIGNED>
and
<PropertyGroup Condition="'$(Cfg_2)'!=''">
(this is the one with <DCC_Define>DEBUG;$(DCC_Define)</DCC_Define>)
<DCC_DebugInfoInExe>true</DCC_DebugInfoInExe>
<DCC_DebugDCUs>true</DCC_DebugDCUs>
<DCC_WriteableConstants>True</DCC_WriteableConstants>
<DCC_IntegerOverflowCheck>True</DCC_IntegerOverflowCheck>
<DCC_RangeChecking>True</DCC_RangeChecking>
<DCC_SymbolReferenceInfo>2</DCC_SymbolReferenceInfo>
<DCC_StackSize>16384,9437184</DCC_StackSize>
<DCC_SYMBOL_DEPRECATED>False</DCC_SYMBOL_DEPRECATED>
<DCC_SYMBOL_LIBRARY>False</DCC_SYMBOL_LIBRARY>
<DCC_SYMBOL_PLATFORM>False</DCC_SYMBOL_PLATFORM>
<DCC_UNIT_LIBRARY>False</DCC_UNIT_LIBRARY>
<DCC_UNIT_PLATFORM>False</DCC_UNIT_PLATFORM>
<DCC_UNIT_DEPRECATED>False</DCC_UNIT_DEPRECATED>
<DCC_COMPARING_SIGNED_UNSIGNED>False</DCC_COMPARING_SIGNED_UNSIGNED>
<DCC_COMBINING_SIGNED_UNSIGNED>False</DCC_COMBINING_SIGNED_UNSIGNED>
and they did not have this PropertyGroup
<PropertyGroup Condition="'$(Cfg_2_Win32)'!=''">
<VerInfo_IncludeVerInfo>false</VerInfo_IncludeVerInfo>
<DCC_DebugInfoInExe>false</DCC_DebugInfoInExe>
<ILINK_FullDebugInfo>true</ILINK_FullDebugInfo>
<BCC_SourceDebuggingOn>true</BCC_SourceDebuggingOn>
<BCC_DebugLineNumbers>true</BCC_DebugLineNumbers>
<BT_BuildType>Debug</BT_BuildType>
<DCC_ImportedDataReferences>false</DCC_ImportedDataReferences>
<DCC_DebugDCUs>false</DCC_DebugDCUs>
</PropertyGroup>
Going through these I think these are the settings they have differently and that may influence the generated .dcu files:
Range checking off {$R-}
Overflow checking off {$Q-}
Local debugs symbols off {$D-}
Runtime assertions off {$C-}
Symbol reference info off {$L-}
Writeable constants off {$J-}
Debug info in exe off {$Y-}
So I put this at the top of dxBar.pas:
{$C-,D-,J-,L-,Q-,R-,Y-}
Nope, no success...
I did not read entirely but immediately checked the DevExpress sources when I saw the compile error.
This is very much related to the fact that TdxBarItemControl.GetItem is marked as inline. When inline or generics (they behave similar) are involved it often is required that if you change such a unit also any other unit using this one has to be recompiled as well.
Suggestion based on experience (we also use DevExpress with custom modifications):
Put them into version control (also the binaries! git lfs ftw) and when you change any of the source just recompile and commit any changes. Keep this repository seperate from your own source repository but tag/branch it identical to your source repository. Changing between versions then also will be a no brainer.
I am not convinced it is about compiler options. I guess there may be a missing cxBarEditItem.pas file. Or there is an old cxBarEditItem.dcu somewhere in your linking path. So the compiler is confused.
Try to clean up the component sources, to have only .pas files and no .dcu, and try to recompile again.
If it is not enough, then maybe this is a problem with the components .inc files, and incompatible options. Don't try to modify the third-party component source code, you will most probably break something.
I just had the same problem, searched it, found this and for me the answer was this: I forgot to add a .pas file for a unit to the .dpr but still had a .dcu for it lying around from another build.
I had to add the file to the .dpr and everything worked again.
I have been playing with the {$IMAGEBASE} directive in Delphi but I can see that I can only put a value lower than $FFFFFFFF (32-bit).
I'm compiling as x64 and I need to set an image base bigger than 32-bit but Delphi ignores the higher 32-bit DWORD in my 64-bit ImageBase.
Has anyone managed to set a value higher than $FFFFFFFF as ImageBase for Delphi?
I need it because I need to test my application in "high" ImageBase (due to some hook tests, etc)
Thanks!
The Delphi linker does not support large image base, although there are new PE optional headers that allow large image base values to be specified.
So I think that until Embarcadero introduce any such functionality, you would need to use a third party tool to rebase the executable file after it has been built. For instance EDITBIN with the /REBASE option from the MS toolchain.
I took a simple 64 bit VCL program, built with XE7, and rebased it like this:
editbin /rebase:base=0xffffff0000 Project1.exe
I confirmed using Process Hacker that the image base was indeed as specified.
I have 32 bit program written in c++ builder xe2, which have dynamicly linked bpl files.
My program update system is based on exe file version. But in some of clients witch windows 2008 serwer 32 bit update system failed, because program see 1.0.0.0 file version instead of 2.3.0.94. When I check properities of file in this windows it shows 1.0.0.0 also.
How to compile exe file to be sure that version will be readable to all editions of windows system?
Your project likely has multiple Build Configurations and you did not define version info in all of the configurations that you compile for. With the introduction of Build Configurations and Option Sets, defining version info has become harder to manage, because users expect to define version info once and have it automatically carry through the various configurations, but that is simply not the case. Users typically have to either duplicate their version info multiple times as needed, or use third-party tools or IDE addons to handle it for them. This is a known shortcoming in Embarcadero IDE versions of recent years, and there are countless discussions about it in the Embarcadero forums.
I am currently using map2dbg to create a .dbg file from my Delphi .map files. This works beautifully for 32 bit executables. For 64 bit executables the call to map2dbg.exe appears to succeed, but the resulting .dbg file does not appear to be useful. When I view stack traces in Process Explorer, they have no symbol names.
Should I even expect map2dbg to work in 64 bit? And if not, is there an alternative that I can use?
I've made a small research and it seems that map2dbg can in fact be used for 64bit executables made in Delphi XE2. The only point is you should modify WORD in the produced DBG file at offset 4 from $8664 to $014C.
Yes, this looks like a nonsense, because this means to change Machine field in DBG header from AMD64 to X86, but this really results in a DBG file correctly loading in both WinDbg and Process Explorer.
I've made a patched version of map2dbg version 1.3, so it automatically writes $14c into DBG. Here is the archive: http://yadi.sk/d/kbVFCGyI2gQzM
UPDATE:
DBG files made with the patched version of map2dbg are accepted by both Process Explorer and WinDbg, and the symbols from these DBGs are correctly linked with the corresponding addresses in the executable, but wrong stack frames are displayed.
The reason is in DBGHELP library. As can be seen from its disassembly, it only loads the DBG files made for X86 or Alpha processors (Machine field values $14c and $184). But if we manually change the Machine field in a DBG file from AMD64 to X86, then DBGHELP will treat the executable as a 32-bit module (so PDATA segment from the executable won't be used during the stack unwind), and incorrect stack frames will be shown by the debuggers.
I've patched both x86 and x64 versions of DBGHELP installed with WinSDK for Win8. The patched versions allow for loading DBG files with AMD64 Machine field ($8664), so the stack frames as displayed as expected. These versions are available in this archive: http://yadi.sk/d/7ZDLv2ed2gRGo
So, we now have two different approaches to use the symbols from 64-bit executables compiled with Delphi XE2:
Simple way: use the patched map2dbg to produce "fake-x86" DBGs, which can be loaded into WinDbg and Process Explorer, so the symbol addresses will be shown, but the debuggers won't be able to display the stack frames.
"Hardcore" way: use the patched dbghelp.dll, with the support of AMD64 DBG files. With this version of DBGHELP, WinDbg and Process Explorer can unwind the stack frames.
ONE MORE UPDATE:
cv2pdb tool can now convert DBG files created with map2dbg into PDBs. Both 32-bit and 64-bit executables are supported.
Here's a compiled version of the latest sources of cv2pdb.
Unfortunately, *.dbg support is deprecated (note: not even used or loaded!) in newer versions of Microsoft products (windbg, process explorer, visual studio etc).
So even if it creates a valid .dbg file, it will never be used... :-(
My biggest wish is to be able to create a .pdb file! So if anyone can get the specs for it?!
(it is a closed MS format?)
Because, to be even worse, the newest Intel VTune/Threading profiler also does not use .dbg files anymore, so I REALLY WANT A DELPHI TO PDB CONVERTER! (sorry for shouting)
I have tried several things, but no success yet.
That's why I created my own stack viewer and minidump viewer, which uses Delphi debug symbols (.map, .jdbg etc):
http://code.google.com/p/asmprofiler/wiki/ProcessStackViewer
http://andremussche.blogspot.com/2011/03/minidump-reader-for-delphi.html
Note: I haven't tested my stuff on 64bit Delphi apps yet... So it probably won't work, but you can try it anyway...
Just for your information: I found a PDB writer
https://github.com/jbevain/cecil/blob/master/symbols/pdb/Mono.Cecil.Pdb/PdbWriter.cs
It's part of the Mono Cecil library (open source .net implementation).
I hope it can modified to read Delphi .map files too...
(not tested yet)
Just for your information, I made a Proof of Concept dll for dbghelp.dll, so
it can also read Delphi .map files.
It is some kind of proxy dll: it has the same exports of the real dll, but
they are all forwarded to the real/original dll. 3 symbol functions are
implemented with a Delphi (jclDebug.pas) lookup:
https://plus.google.com/u/0/110131086673878874356/posts/4rmyQM5kVW7
https://plus.google.com/u/0/110131086673878874356/posts/TSJRqFJR3WZ
Only 32bit for now. ProcesExplorer runs only in 64bit in a 64bit Windows, but
ProcesHacker also has a 32bit version. When I have some more time I can maybe
improve it further... or try it yourself in the mean time! In 64bit mode you
cannot use "ASM JMP PToProc" but something like "ASM JMP qword ptr [rel p]".
I made some modifications (actually commented the exceptions :-) ) to tds2pdb.
Now it also works for Delphi .tds files, both 32bit and 64bit!
See my G+ post:
https://plus.google.com/u/0/110131086673878874356/posts/eJBKC16e5f6
Note: only ProcesExlorer did not show the full stack of my 64bit test program, ProcesHacker and WinDbg show the full stack though.