Tuesday, January 21, 2014

.NET x86 vs x64 hell (BadImageFormatException)

As far as I know, .NET platform architecture were similar to JVM's architecture, each .NET assembly or DLL consist of intermediate language (IL) bytecodes similar to JVM bytecode. So in theory, there suppose to be no problem running .NET DLL in x64 platform without using 32-bit support, right?

It turns out the reality is not like that. I recently found out that there is 3 kind of target in Visual Studio Project settings :
  • Anycpu
  • x86
  • x64
For Anycpu, the resulting DLL is loadable in both environment (x86 and x64). The x64 target is only loadable in 64-bit platform. The x86 target would ensure the resulting DLL runs either in 32 bit platform or, in case of physical 64-bit platform, in the WOW64 x86 emulator. This means such DLL would be unable to run in real-64 bit environment, such as in Microsoft IIS with 32-bit app support flag turned off.

The characteristic of such DLL can be determined using Corflags.exe tool :

D:\sources\SmileDevRoot\Code\az_source>corflags obout_AJAXPage.dll
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  3.5.21022.8
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v2.0.50727
CLR Header: 2.5
PE        : PE32
CorFlags  : 9
ILONLY    : 1
32BIT     : 0
Signed    : 1

 PE32 : this means 32-bit executable format. This format is readable both in x64 (64 bit) and x86 (a.k.a 32-bit) environments. The opposite : PE32+, the format that only readable in x64 environment
 ILONLY : 1 means the DLL only contains IL code. The opposite, 0, means the DLL contains mix of native (32-bit or 64-bit) code modules and IL code module.
32BIT : 0 means the DLL could run both in 64 and 32 bit environments. The opposite, 1, means the DLL must be run in 32 bit environment.

So, even though the DLL consists of only IL code, and no native x86/x64 code, a DLL with 32BIT set to 1 still would refuse to load on x64 platform, resulting in BadImageFormatException.  Why on earth someone would want to do that? Well, the DLL might calls functions from a native 32-bit DLL.
But you might want to try to force this DLL to run in 64-bit mode, to see whether it actually need a 32-bit platform or not :

D:\sources\SmileDevRoot\Code\az_source>corflags obout_ASPTreeView_2_NET.dll
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  3.5.21022.8
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v1.1.4322
CLR Header: 2.0
PE        : PE32
CorFlags  : 11
ILONLY    : 1
32BIT     : 1
Signed    : 1
D:\sources\SmileDevRoot\Code\az_source>corflags obout_ASPTreeView_2_NET.dll /32B
IT-
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  3.5.21022.8
Copyright (c) Microsoft Corporation.  All rights reserved.

corflags : error CF012 : The specified file is strong name signed.  Use /Force t
o force the update.
 Well, it failed at the first try. I will post here if there is any progress in forcing this DLL into 64 bit mode :)

Monday, January 20, 2014

Domino error Server exiting: Partition already in use

Cause : 

Unknown thing caused domino crash

Effects

Unable to restart domino server. There was an error message :
Server exiting: Partition already in use
 On Solaris platform, ps -ef shows many processes still running from under the notes_apps directory.

Solution

List notes process pids using
ps -ef | grep

Kill each and every notes processes (amgr, router, http, etc) :
kill
kill -9