System.BadImageFormatException: Problem in 64bit Widows 7 and Windows Server

Topics: Bugs
Feb 7, 2011 at 2:17 PM

Exception:

System.BadImageFormatException: Could not load file or assembly 'GMap.NET.Core, Version=1.3.8.4, Culture=neutral, PublicKeyToken=b85b9027b614afef' or one of its dependencies. An attempt was made to load a program with an incorrect format.

File name: 'GMap.NET.Core, Version=1.3.8.4, Culture=neutral, PublicKeyToken=b85b9027b614afef'

   at MSMainPrj.FormsEmbedded.MapForm.InitializeComponent()

   at MSMainPrj.FormsEmbedded.MapForm..ctor(Double latitude, Double longitude, String source, String locationName, Int32 venueId)

 

Application works fine in 32 bit OS.

Coordinator
Feb 7, 2011 at 4:27 PM

use x86 target and you will be ok

Feb 8, 2011 at 6:13 AM

Hi radioman thanks, in my setup target is already set x86.

Jan 19, 2015 at 1:07 PM
We have the same issue on a Citrix XenApp 6.5, Windows Server 2008 R2. The executable is x86 (Have verified this with corFlags). The application runs without issues on all Desktop flavours (XP->Win8 | x86 + x64)

Note: Memory Optimization is disabled on the server. Citrix Virtual Memory Optimization Service can lead to .NET application corruption. http://support.microsoft.com/kb/2480607

Hope you have some ideas. In the meantime, we'll investigate to see if we find any traces of System.Data.SQLite.DLL in the Local AppData folder.
Jan 19, 2015 at 1:08 PM
Edited Jan 19, 2015 at 2:52 PM
The IntPtr.Size == 8 ? test seems to work as expected.

The System.Data.SQLLite.DLL assembly is located in the
Users\<?>\AppData\Local\GMap.Net\DllCache\SQLlite_v84_NET2_x86 folder.

Any ideas ?

--- Stack Trace ---
Exception Information: System.TypeInitializationException: The type initializer for 'GMap.NET.WindowsForms.GMapControl' threw an exception. ---> System.BadImageFormatException: is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
at GMap.NET.CacheProviders.SQLitePureImageCache.Ping()
at GMap.NET.GMaps.SQLitePing()
at GMap.NET.WindowsForms.GMapControl..cctor()
--- End of inner exception stack trace ---
at GMap.NET.WindowsForms.GMapControl..ctor()
at WinApp.Forms.GMapViewForm.InitializeComponent()
at WinApp.Forms.GMapViewForm..ctor()
Coordinator
Jan 19, 2015 at 3:07 PM
hm..

can you make test console app x86 and test this line?
System.Reflection.Assembly.LoadFile("Users\<?>\AppData\Local\GMap.Net\DllCache\SQLlite_v84_NET2_x86\System.Data.SQLLite.DLL");
Jan 19, 2015 at 4:25 PM
Thanks for looking into this.

The customer has outsourced the Citrix Server Management and has consequently limited access. I.e. it is a bit tricky to ask the service provider to carry out lots of tests. There are no servers rigged up for testing either which makes it even harder.

If this is the only route forward, we will give it a shot. However, if you have any other methods to suggest and/or other tests we can run at the same time, that would be highly appreciated.

PS: Apologies for not starting my question with complementing the work you have put into this project. Absolutely fabulous !!!
Coordinator
Jan 19, 2015 at 4:40 PM
i see, ..well i would check all combination and if any would work at all, thats the idea
Jan 28, 2015 at 12:58 PM
Edited Jan 29, 2015 at 9:36 AM
Hi Radioman,
We managed to get the service provider to run a test on a Citrix Client that fail and the LoadFile call works fine. (I was sort of hoping for a different result).

We're a bit stuck now - any suggestions would be very much appreciated.

PS: Not that this should make any difference to the test-result, but the LoadFile test is executed directly from an standard executable. The failing callstack goes via a form that is located in an assembly.

UPDATE:
Everything works fine when running as local admin. Still a problem for users with normal privileges. This rules out a number of scenarios. We have been given some assistance to test this on another Citrix in the next few days and see if get a bit more insight.
Feb 13, 2015 at 9:35 AM
Hi Radioman,
The service provider finally managed to "escalate" this issue and had one of their more experience technicians looking at the problem.

It turned out that they had AppSense working in the background which was blocking execution. AppSense is suppose to write execution blocking to the eventlog, but I never got this confirmed. Everything works fine after they updated the AppSense policy.

Conclusion: Fault finding without access and limited information can feel close to impossible, but you'll get there in the end with perseverance.
Marked as answer by radioman on 2/13/2015 at 2:40 AM
Coordinator
Feb 13, 2015 at 10:48 AM
Thanks for sharing!