0

We have a C# application, that is compiled as a AnyCPU. This application uses an external library(which is also a .Net DLL on AnyCPU) that loads some C++ libraries in externals DLL.

Thoses externals libraries are either for X86, either for X64. We have a postbuild event that copies the one from X64 into the output folder.

We had everything working since years, and we have a lot of unit tests using this library.

Recently, on one computer(the build machine), the UnitTests now fails, with the following call stack.

The type initializer for 'Dew.Math.Units.MtxParseClass' threw an exception.
   at System.Runtime.CompilerServices.RuntimeHelpers._RunClassConstructor(RuntimeType type)
   at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
   at Dew.Math.TExprContext..cctor()

The type initializer for 'Dew.Math.Units.MtxVec' threw an exception.
   at System.Runtime.CompilerServices.RuntimeHelpers._RunClassConstructor(RuntimeType type)
   at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type)
   at Dew.Math.Units.MtxParseClass..cctor()

An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
   at Dew.Math.Units.Nmkl.kmp_set_blocktime(Int32 Value)
   at Dew.Math.TMtxVecController..ctor()
   at Dew.Math.Units.MtxVec.InitializeMtxVec()
   at Dew.Math.Units.MtxVec.Dew.Math.MtxVec()
   at Dew.Math.Units.MtxVec..cctor()

We have verified the C++ DLL are in 64 bits, our application is in AnyCPU on a 64 bits computers, so normally we should not have thoses errors.

The weird part is that: We didn't touch anything to thoses tests or on the tested classes, the tests still works fine on all other computers.

So my question:

How to debug it:

  • How to know the exact path of the DLL that fails being loaded
  • How to be sure that we are executed in X64 and not x86?
  • Any other idea to help me troubleshot this issue?
J4N
  • 19,480
  • 39
  • 187
  • 340
  • 1
    Invariably this is 32/64 bit mismatch. If your DLLs are 64 bit then your .net code should target 64 bit, not AnyCPU. – David Heffernan Sep 06 '17 at 11:06
  • @DavidHeffernan 1) I know this is a 32/64 mismatch, I'm trying to figure out WHY. 2) I disagree. Creating AnyCPU DLL will allow you to have this DLL used by 64 or 32 bits executable. The question you refers doesn't give any hint on how to find which DLL is loaded by the external library. – J4N Sep 06 '17 at 11:49
  • So when you change the target to 64 bit then you observe the same failure? – David Heffernan Sep 06 '17 at 11:52
  • @DavidHeffernan I cannot do that easily, we have more than 350 projects in the solution and no target for the 64bits platform, it's because of this that we use AnyCPU, like this we can do the configuration only once per project. What I found is that if I run the tests with NUNIT-CONSOLE, it's executed as `Environment.Is64BitProcess == false`. If I execute them through resharper, I got `Environment.Is64BitProcess ==true` – J4N Sep 06 '17 at 11:54
  • Why are you fighting this? You know that you need a 64 bit process. – David Heffernan Sep 06 '17 at 11:55
  • @DavidHeffernan Just to mention: https://msdn.microsoft.com/en-us/library/ee782531.aspx It clearly states that to execute my tests as 64bits tests, I should opt for the AnyCpu or the *Optionally* the x64 – J4N Sep 06 '17 at 11:56
  • @DavidHeffernan No, we also distribute a 32 bit version of our application. For which we give differents version of the external libraries(but the same exact DLL for our app) – J4N Sep 06 '17 at 11:56
  • There's no helping some people. The system is telling you that you have a bitness mismatch. Why can't you accept that? – David Heffernan Sep 06 '17 at 11:58
  • @DavidHeffernan I don't "accept" it because the same exact code, with the same exact libraries works on some 64Bits computers and doesn't on some other. I'm trying to figure out why. Also, I don't know WHICH dll has this issue. – J4N Sep 06 '17 at 12:10
  • Anyway, this question isn't the same than the one you mentionned, it has certainly the same root cause, but it's definitely not the same question. – J4N Sep 06 '17 at 12:11
  • Step 1, find out the process bitness – David Heffernan Sep 06 '17 at 12:13

1 Answers1

0

Note that using AnyCPU on x64 prefers 32bit. You can change this in the build settings for the project

Tom Schardt
  • 470
  • 1
  • 7
  • 18
  • I saw this options, but it's only for executable, for library and unit tests, you cannot specify that. – J4N Sep 06 '17 at 11:49
  • @J4N: Yes, of course. The application decides the bitness of all stuff running in context. – Tom Schardt Sep 06 '17 at 12:41