Windows Service throws System.BadImageFormatException on Windows Server 2008, x64, .NET 4 migrated from 3.5

5
votes

I have tried compiling the service EXE file as AnyCPU, x86, and x64. It works on my Windows 7 x64 box. I'm installing with installutil, the .NET 4 version.

When I start the service, I get an error. It says nothing, but it does point to which modules are loaded. Those of potential interest:

LoadedModule[0]=D:\yellowbook\grapevine_service\grapevinesystemservice.exe LoadedModule3=C:\Windows\system32\KERNEL32.dll LoadedModule4=C:\Windows\system32\KERNELBASE.dll LoadedModule[9]=C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscoreei.dll LoadedModule[17]=C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll LoadedModule[18]=C:\Windows\WinSxS\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927_none_88dce9872fb18caf\MSVCR80.dll LoadedModule[22]=C:\Windows\assembly\NativeImages_v2.0.50727_64\mscorlib\9a017aa8d51322f18a40f414fa35872d\mscorlib.ni.dll

I can run this service as a console application with a command-line switch, which yields this:

Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'grapevinesystemservice.exe' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. File name: 'grapevinesystemservice.exe'

I've tried to the registry hack to force the use of the latest runtime. No effect. I've looked at the installed EXE file in reflect to make sure it didn't get munged by my buildserver, but it's targeted at 4.0.30319. My local, build, and test server all have 30319 as the .NET 4 version. None ever had a beta/RC.

They weren't listed in the load modules, but I am also using log4net (rebuilt in .NET 4 from source code), StructureMap, NoRM (MongoDB), AutoMapper, Newtonsoft.Json, and a number of other DLL files that were built by my team.

4
.net.net-3.5windows-services.net-4.0windows-server-2008
Event log usually contains additional information if a service fails to start. Did you check that? Did you also make sure that all referenced assemblies are targeting .NET 4.0 have the correct bitness? It seems your service is using the .NET 2.0 version of mscorlib. – Dirk Vollmar
Yeah, the event log was surprising devoid of anything useful, other than the link to the dump file that listed the loaded modules... I didn't include that simply because the question was already so long that I was afraid of scaring people away. :-) Thanks for the poiter though. – Jeff D
Just to check whether the issue is with your project or with your server: Does a simple, newly created .NET 4.0 service install and run perfectly? – Dirk Vollmar
That was going to be my next plan. I was dragging my feet because security makes it so hard to get code from here to there. If this .net framework repair (see below) doesn't fix it, that's my next plan. Thanks again for another good suggestion. Actually, if it turns out that my framework install was busted, your first answer will have been 100% spot on as well. – Jeff D

4 Answers

6
votes

Have you tried setting requiredRuntime in the config file for grapevinesystemservice.exe? Like 0xA3 mentioned, it looks like it isn't set to use 4.0.

<startup>
  <requiredRuntime version="v4.0.20506" safemode="true"/>
</startup>
3
votes

One of your dependent DLL files has not been compiled with AnyCPU. See Stack Overflow question How to determine if a .NET assembly was built for x86 or x64? for details on how to check them.

1
votes

I have also seen above issue during installing the service using installutil. The issue was that I installed .NET 4 Framework using dotNetFx40_Full_setup.exe from MSFT. The installer does NOT add references to 4.0 Framework to your system PATH environment variables.

Add the following to your PATH environment variable:

c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;c:\WINDOWS\Microsoft.NET\Framework\v3.5

This worked for me during the install as well as during runtime.

0
votes

I found another reason for this issue: if you have multiple .NET frameworks installed on your web service, using installutil.exe will default to the oldest version. This can cause problems if the service you are installing relies on a newer version of the framework.