1

I adopted a code base that I need converted to 32-bit (so I can use an external 32 bit driver). I set the project Platform Target to x86 (picture below). It all compiles fine, but for some reason at run time it crashes and produces the following output An unhandled exception of type 'System.BadImageFormatException' occurred in mscorlib.dll .

Project Platform Target

I used Dependency Walker, and found out that some of the DLLs linked in are 64 bit, located in \System32\ when I want the 32 bit DLLs located in "SysWOW64". (Ouptut Below). You can see from the output that the directories are incorrect, and that they are indeed 64 bit DLLs. I thought this was all managed by windows?

enter image description here

So my question is, how do I force the application to go to the 32 bit DLLs in \SysWOW64\? Is this a windows configuration setting or a project setting? Or how can I diagnose the problem further?

Ryan
  • 314
  • 1
  • 10
  • Why aren't you configuring your Platform for the project? – Maximilian Burszley Jan 17 '19 at 19:51
  • silly question, but when was the last time you cleaned the solution? – user1666620 Jan 17 '19 at 19:51
  • I have cleaned and rebuilt multiple times. "Why aren't you configuring your Platform for the project?" I'm not sure exactly what you mean. Why aren't I specifying an exact CPU type where it says 'Platform'? – Ryan Jan 17 '19 at 19:54
  • What kind of project is this? Asp.Net, WinForms, WPF, Service, etc... – StingyJack Jan 17 '19 at 20:00
  • Note that compiled managed dll does not include path to native dll, but only its name. – user4003407 Jan 17 '19 at 20:00
  • This is a WinForm project. What exactly are you suggesting 'PetSerAI'? – Ryan Jan 17 '19 at 20:03
  • @Ryan - then it could be the win form project, the driver, or another dll reference that is causing the image format exception. The way to tell for sure is to use the Fusion log to find out what assembly the runtime is trying to load and from where. – StingyJack Jan 17 '19 at 20:06
  • Usually they way to interop with any specific binarity: a)Make awrapper programm/service/whatever only for it. b) Let the wrapper programm and programm proper talk via Interprocess Communication. That way only the smalest part needs a fixed binarity, avoiding a lot of issues that forcing a specific binarity can bring. With a large project it could even be that **another** piece of code needs x64, while you try to force x32. Resulting a catch 22. – Christopher Jan 17 '19 at 20:11
  • @Ryan I suggest you to confirm that error actually is, what you think it is. For example, did you try to get working 32-bit managed dll and give it to Dependency Walker? Did it actually resolve dependencies to `SysWOW64` directory? Maybe Dependency Walker just always resolve dependencies for managed dlls to `System32` regardless of its bitness? If that so, then all Dependency Walker info in your question is irrelevant to your problem. Also did you try to use some runtime monitoring tool (like Sysinternals Process Monitor) to detect what dlls your process access at runtime? – user4003407 Jan 17 '19 at 20:22
  • Dependency Walker has not been maintained in a very long time and is useless to diagnose this problem. It does not know anything about the file system redirector that redirects to syswow64. Setting the platform target on a DLL is not useful either, it is the EXE project that locks in the process bitness. – Hans Passant Jan 17 '19 at 20:27

1 Answers1

-1

I think you need to set the Platform dropdown from Active (Any CPU) to 32-bit.

Active solution platform VS Project Platform VS Platform target

According to the above, with Active (Any CPU), the assemply will be JIT to suit the platform it's running on, so x86 on a 32-bit plaform, and x64 on 64-bit platforms.

Additionally, it may be necessary to configure the MSIL:

https://stackoverflow.com/a/10196549/1666620

  1. Go to the Build|Configuration Manager menu item.
  2. Find your project in the list, under Platform it will say "Any CPU"
  3. Select the "Any CPU" option from the drop down and then select
  4. From that dialog, select x86 from the "New Platform" drop down and make sure "Any CPU" is selected in the "Copy settings from" drop down.
  5. Hit OK
  6. You will want to select x86 for both the Debug and Release configurations.
user1666620
  • 4,800
  • 18
  • 27
  • I just tried that and unfortunately the results are identical. – Ryan Jan 17 '19 at 19:58
  • Its nice if you can get all the projects in the solution to match the solution configuration and platform target, but that isn't always possible. If this is the only project in the solution, or all of the projects in the solution need this bitness, then the OP should strongly consider this advice just to make the solution easier to understand. – StingyJack Jan 17 '19 at 20:04