I'm working with an application that uses 2 library, the first is stored outside of my project under c:\windows\system32 folder and it is used with:
[DllImport("FWLIB32.dll", EntryPoint="cnc_settimeout")]
public static extern short cnc_settimeout( ushort FlibHndl, int a );
The second one is imported in the Project references.
I need to use both of them, but if I config Visual studio to compile it with platform: "Any CPU" (and prefer 32bit) the first works and the second doesn't work, id I set platform x86 the second works but not the first.
In both cases it is thrown System.BadImageFormatException.
How to work with both dll? Is it possibile?
This is the first dll details:
PE details
Date compiled: Thu, July 21, 2011, 10:19:34 PM
Linker version: 6.0
Machine type: Intel 386 or later processors and compatible processors
PE format: PE32
Characteristics: Dynamic-link library
DLL Characteristics: None
Subsystem: The Windows graphical user interface (GUI) subsystem
Min OS: Windows 95
Min OS version: 4.0
Subsystem version: 4.0
File version: 0.0
Manifest: No
Images: No
Icons: No
Dialogs: Unknown (Not implemented)
String tables: Unknown (Not implemented)
Accelerators: Unknown (Not implemented)
Cursors: Unknown (Not implemented)
Menu: Unknown (Not implemented)
More details
designedFor: 32-bit Windows
typeOfFile: DLL
fileVersion: 5.9.0.1
productVersion: 5.9.0.1
Comments: DCompanyName
CompanyName: FANUC CORPORATION
FileDescription: Data Window Library for Win32
FileVersion: 5, 9, 0, 1
InternalName: Fwlib32
LegalCopyright: Copyright (C) 1996-2011 FANUC CORPORATION
LegalTrademarks: #OriginalFilename
OriginalFilename: Fwlib32.dll
PrivateBuild: TProductName
ProductName: FANUC Data Window Library
This is the second one details:
PE details
Date compiled: Fri, December 7, 2012, 9:25:47 AM
Linker version: 10.0
Machine type: x64
PE format: PE32+
Characteristics: Application can handle > 2GB addresses (Large address aware); Dynamic-link library
DLL Characteristics: Image is NX compatible (No eXecute)
Subsystem: The Windows graphical user interface (GUI) subsystem
Min OS: Windows XP 64-Bit Edition / Windows Server 2003 / Windows Server 2003 R2
Min OS version: 5.2
Subsystem version: 5.2
File version: 0.0
Manifest: Yes (406 bytes)
Images: No
Icons: Yes (2 icons)
Dialogs: Unknown (Not implemented)
String tables: Unknown (Not implemented)
Accelerators: Unknown (Not implemented)
Cursors: Unknown (Not implemented)
Menu: Unknown (Not implemented)
More details
designedFor: 32-bit Windows on Windows NT
typeOfFile: DLL
fileVersion: 4.0.0.0
productVersion: 4.0.0.0
CompanyName: Siemens
FileDescription: Rpc Sinumerik Assembly
FileVersion: 4.0.0.0
InternalName: Siemens.Sinumerik.Rpc.dll
LegalCopyright: Copyright (C) 2012
OriginalFilename: RpcSinum.dll
For me are both 32bit... but Why the first one works only with "Any CPU" option?
Related
32bit Application developed in c# with VLC player 32bit dll components getting crashed. Below provided the crash details and system information. Please give me an quick solution.
System information:
OS:Windows 10 pro 64bit
Processor: I7-7700 CPU # 3.60 GHz
Graphics card: Nvidia Quadro 600
RAM: 32GB
System Model: Precision Tower 3620 Dell
Bios: 2.8.1
Directx: 12
Inbuilt Graphics: Intel HD Graphics 630
Source
Cyphy VideoMonitor Client
Summary
Stopped working
Date
27-12-2018 16:37
Status
Report sent
Description
Faulting Application Path: C:\Program Files (x86)\Cyphy Client Applications\VMS_VideoMonitor.exe
Problem signature
Problem Event Name: APPCRASH
Application Name: VMS_VideoMonitor.exe
Application Version: 1.3.9.4
Application Timestamp: 5c23a950
Fault Module Name: nvd3dum.dll
Fault Module Version: 23.21.13.9125
Fault Module Timestamp: 5aab746d
Exception Code: c0000005
Exception Offset: 007ef1e4
OS Version: 10.0.17134.2.0.0.256.48
Locale ID: 16393
Additional Information 1: 2beb
Additional Information 2: 2beba6fb4680d73a8c78ca7c24ccdb46
Additional Information 3: 5e24
Additional Information 4: 5e242fda7d18813327ab5a22faeed05c
Extra information about the problem
Bucket ID: aaf891aea295151974dcff40831e65f8 (1503357028177700344)
To analyze crashes always use Microsoft's crash dump analysis tool. You can download it here:
https://support.microsoft.com/en-ph/help/2580960/debug-diagnostics-tool-v1-2-is-now-available
You can never tell the reason behind a crash from the source code alone, this tool helps you identify possible reasons for the crash.
Here is a good tutorial: https://stackify.com/using-windbg-to-analyze-net-crash-dumps-async-crash/
I´m receiving the following logs from the system events. I have no idea why this only happens on some machines:
Level: Information; Source: Windows Error Reporting
Detail: 756021398 30 CLR20r3 Not available 0 DayZ Ambient Launcher.exe 1.0.0.0 59d3d3b2 System.Windows.Forms 4.7.2558.0 59d4145b 63d 36 PSZQOADHX1U5ZAHBHOHGHLDGIY4QIXHX
C:\Users\kevo1414\AppData\Local\Temp\WERAA52.tmp.WERInternalMetadata.xml C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_DayZ Ambient Lau_4e74decfa163bcb1cc9a3fc7dd961b8b6b975b8_108bafbf
0 093ea276-bf39-11e7-b709-902b345e4b59 0
Level: Error Source: Application Error
Detail:
DayZ Ambient Launcher.exe 1.0.0.0 59d3d3b2 KERNELBASE.dll 6.1.7601.23915 59b94abb e0434352 0000c54f 1498 01d35345cae21649 C:\Users\kevo1414\Downloads\DayZ Ambient Launcher 1.1 [eXWoLL,Cobblest0ne]\DayZ Ambient Launcher.exe C:\Windows\syswow64\KERNELBASE.dll 093ea276-bf39-11e7-b709-902b345e4b59
Level: Error Source: .NET Runtime
Detail:
Application: DayZ Ambient Launcher.exe Framework Version: v4.0.30319 >Description: The process was terminated due to an unhandled exception. Exception Info: System.Runtime.InteropServices.COMException at System.Windows.Forms.UnsafeNativeMethods.CoCreateInstance(System.Guid ByRef, System.Object, Int32, System.Guid ByRef) at System.Windows.Forms.AxHost.CreateWithLicense(System.String, System.Guid) at System.Windows.Forms.AxHost.CreateInstanceCore(System.Guid) at System.Windows.Forms.AxHost.CreateInstance() at System.Windows.Forms.AxHost.GetOcxCreate() at System.Windows.Forms.AxHost.TransitionUpTo(Int32) at System.Windows.Forms.AxHost.CreateHandle() at System.Windows.Forms.Control.CreateControl(Boolean) at System.Windows.Forms.Control.CreateControl(Boolean) at System.Windows.Forms.AxHost.EndInit() at dayz64.Form1.InitializeComponent() at dayz64.Form1..ctor() at dayz64.Program.Main()
There are two possible causes that I can see: operating system mismatch, or .NET installation mismatch.
Windows 7 was around right when x64 was being introduced, so there are some installations that either use x32 or x64, and going between them can result in issues if you don't install the right version of the application.
If you're going to run this application on a Windows 7 computer, then open the Start Menu, right click on Computer, and click on properties. You can see the specs of the operating system you're running from there.
The second possible issue is a .NET installation issue - maybe you have an outdated version of .NET installed, or the application relies on a legacy version of .NET and can't run on the newer frameworks, in which case you would need to look up the specifications of the product and the version you're using.
Hope this helped!
I created a project and compiled it as Any CPU. on x64-Windows. As I have trouble to reference that assembly from my code I checked the runtime and the target-plattform:
As you can see the target plattform is x64 when running on an x64-OS (as mine). I checked DumpBin also:
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (x86)
3 number of sections
57A49000 time date stamp Fri Aug 05 15:09:20 2016
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
102 characteristics
Executable
32 bit word machine
However when I run CorFlags it´s giving me x64 as plattform for that assembly:
Version : v4.0.30319
CLR Header: 2.5
PE : PE32
CorFlags : 9
ILONLY : 1
32BIT : 0
Signed : 1
As far as I understand when I chose Any CPU as target platform the OS will chose how to execute the assembly. On an 64bit system it´ll run in 64bit, on 32bit-OS as 32bit respectivly.
So my question is: what version am I actually targetting? 32 or 64bit?
That's entirely normal. AnyCPU means that it can run on any cpu so the machine field in the header cannot be relevant. Having to pick something, it just picks x86. Keeps it compatible with ancient Windows versions like Win98 and Win2k.
The special heroics happen on a 64-bit operating system, the OS loader needs help to creating a 64-bit process from a 32-bit executable, that requires patching internal loader structures. The mscoree.dll "loader-shim" gets that job done as described in the linked post.
So you do not target any particular version. It truly is AnyCPU.
For the first time I have noticed that one of the mscordacwks DLLs in my collection is different (SVN told me). As I did some research I figured out that there are LDR versions and GDR versions of those DLLs.
For the files in question I noticed that one of them is not digitally signed, but the other one is (by Microsoft luckily).
So now I have the following questions:
If I have an LDR and a GDR version, how do I figure out which one is which?
Are both, GDR and LDR version of the DLL, signed by Microsoft?
Since one of them isn't signed, could someone inject malicious code into mscordacwks.dll which then gets executed on my machine with debugging privileges when I use it in WinDbg?
I'll try to find out where I got the unsigned DLL from. It is quite likely that I downloaded it from some some more or less dubious website when I needed that particular version.
FYI: the VirusTotal analysis did not reveal any viruses.
Thanks to the help in the comments I can summarize:
Digital signatures
According to Hans Passant, all Microsoft DLLs should be signed, so we have to be careful with unsigned ones.
Unfortunately this statement is not 100% true which I verified for the Mscordacwks.dll 2.0.50727.312 and SOS.dll 2.0.50727.312. Microsoft has shipped that version with Windows Vista. I tried that by installing Windows Vista from scratch.
This is the output of sigcheck -h on the DLL which come with Windows Vista:
Verified: Unsigned
Link date: 09:05 19.10.2006
Publisher: Microsoft Corporation
Description: Microsoft .NET External Data Access Support
Product: Microsoft« .NET Framework
Prod version: 2.0.50727.312
File version: 2.0.50727.312 (rtmLHS.050727-3100)
MachineType: 32-bit
MD5: 9252D83D169E84A442BB154A79AC2189
SHA1: 63464F337295D689384BAA514F260C54D06291C6
PESHA1: 99D57B38C554FFD4BEC6E6C2FAD7F77B980CB47B
PE256: EF387EF84028497D5F7D231ED3A6F5FB05C02D96BD3B0E470C6BEBFAD6942AC8
SHA256: 5ADB79D39FC8401CB9542B571EEEC82CAFCADAE2F26997C789E14EC8E9635C08
And also see the detailed information from VirusTotal which has the same hash codes. Please note the fact that the website is a bit misleading by listing "Authenticode signature block". In fact that is just the version information of the file. The most important line labelled "Signature verification: Signed file, verified signature" is missing for this DLL.
This is how it should look like if the file was really signed:
The output of sigcheck and Windows Explorer also show that that the file is not signed:
Verified: Unsigned
Link date: 09:05 19.10.2006
Publisher: Microsoft Corporation
Description: Microsoft .NET External Data Access Support
Product: Microsoft« .NET Framework
Prod version: 2.0.50727.312
File version: 2.0.50727.312 (rtmLHS.050727-3100)
MachineType: 32-bit
Screenshot of Windows Explorer where the file does not have a digital signatures tab:
At the end of the VirusTotal report, you find a statement by NIST (National Institute of Standards and Technology) which says that the file is delivered with Windows Vista Ultimate and that it seems to be safe. This is the website I am being led to after I uploaded an unsigned version.
Distinguishing GDR and LDR versions
The SysInternals sigcheck tool displays more information on the version number than Windows Explorer. If it includes "GDR", it is a GDR version. If it does not contain GDR, it is an LDR version.
To get a string for comparison in C#, you can use the following code:
var versionInfo = FileVersionInfo.GetVersionInfo(fullFileName);
var fileVersion = versionInfo.FileVersion;
Affected versions
I checked all my DLLs for signatures and found more unsigned DLLs than expected. However, most files have already been scanned on VirusTotal before. However, none of these versions has a NIST entry.
x86 SOS 1.1.4322.2032 VirusTotal
x86 SOS 2.0.50767.312 VirusTotal
x86 Mscordacwks 2.0.50767.312 VirusTotal
x86 Mscordacwks 2.0.50767.3603 VirusTotal
x86 Mscordacwks 2.0.50727.3623 VirusTotal
x64 SOS 2.0.50767.3074 VirusTotal
x64 Mscordacwks 4.0.30319.1008 VirusTotal
Malicious code injection
As stated by Jeroen Mostert, the DLLMain entry point will be executed, therefore there is the possibility of malicious code injection.
TFS have issued the following warning:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets
(1605): There was a mismatch between the processor architecture of the
project being built "MSIL" and the processor architecture of the
reference
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Data.dll",
"AMD64". This mismatch may cause runtime failures. Please consider
changing the targeted processor architecture of your project through
the Configuration Manager so as to align the processor architectures
between your project and references, or take a dependency on
references with a processor architecture that matches the targeted
processor architecture of your project.
Both "Release" and "Debug" configurations are set to use "Any CPU" as an active solution platform.
I took a copy of System.Data.dll into the TEMP folder and extracted information about this assembly through PowerShell:
function ScanAssembly($assemblyPath) {
[reflection.assemblyname]::GetAssemblyName($assemblyPath)
}
$assemblyPath = "C:\TEMP\System.Data.dll"
$assemblyInfo = ScanAssembly($assemblyPath);
$assemblyInfo | fl;
I got the following output:
Name : System.Data
Version : 4.0.0.0
CultureInfo :
CultureName :
CodeBase : file:///C:/TEMP/System.Data.dll
EscapedCodeBase : file:///C:/TEMP/System.Data.dll
ProcessorArchitecture : Amd64
ContentType : Default
Flags : PublicKey
HashAlgorithm : SHA1
VersionCompatibility : SameMachine
KeyPair :
FullName : System.Data, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=...
For some reason, the ProcessorArchitecture for this assembly is set to Amd64. I'm confused as to why it's set to Amd64, because I'm running a 64-bit operating system on an Intel processor.
These warnings are not show stoppers, but I'm struggling to understand as to why we are seeing them. If I understand this correctly, the configuration is set to any CPU, when one of the assemblies is compiled for Amd64, which implies that it will no longer work on any CPU - it'll work only on 64 bit CPU. Why the System.Data.dll is built for Amd64 is beyond me.
Thank you.
You're correct about why these errors are occurring. If a referenced assembly targets a specific framework, the compiler warns that your application can't run on "Any CPU" because the referenced assembly has limitations.
We had this issue on our test and production servers with System.Data and other DLLs. We resolved it by installing the .Net Framework SDK. To do that:
Find the correct SDK. Our environments are set up with Windows Server 2008 and .Net Framework 4.5, so we used the Windows 8 SDK.
Install only the .Net Framework 4.5 SDK (after you accept the license, there's a screen with several checkboxes; I only left the last one checked).
The SDK adds a new version of System.Data.dll in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5. Examining that assembly, you can see that the ProcessorArchitecture is set to None.
Name : System.Data
Version : 4.0.0.0
CultureInfo :
CultureName :
CodeBase : file:///C:/Program Files (x86)/Reference\Assemblies/Microsoft/Framework/.NETFramework/v4.5/System.Data.dll
EscapedCodeBase : file:///C:/Program%20Files%20(x86)/Reference%20Assemblies/Microsoft/Framework/.NETFramework/v4.5/System.Data.dll
ProcessorArchitecture : None
ContentType : Default
Flags : PublicKey
HashAlgorithm : SHA1
VersionCompatibility : SameMachine
KeyPair :
FullName : System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
The other option is to configure your project to target 64-bit processors if that's an option, but our team chose to go the SDK route.