1

I've found a fair bit of information related to how a .NET assembly should load based on the flags set in the assembly header. Pages such as Flipping bits on managed images to make them load with the right bitness... seem to suggest that if you have a header as follows.

PE : PE32 

ILONLY : 1

32BIT : 0

It has been compiled as "Any CPU", and I can expect it to load with the 32-bit CLR on 32-bit platforms and with the 64-bit CLR on 64-bit platforms. This is exactly the behaviour I expected and wanted.

Unfortunately that doesn't appear to be the case on my Windows 7 64-bit machine. The assembly loads up in a 32-bit address space. I know I should be able to force the issue at compile time by building with x64, but why is it doing the wrong thing in the first place?

How can I fix this problem? Is it some registry or environment problem that I've yet to stumble upon?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
jmellor
  • 11
  • 2
  • Is your assembly linked with 3. party 32 bit assemblies or native dlls in some way ? – nos Sep 20 '10 at 16:32
  • I do not think so. I ran depends.exe on the assembly and all dlls had CPU type of x64 (other than IESHIM.dll which wasn't found at all but some searching seemed to suggest this generally happens and is not the source of the problem). The assembly (executable) itself was listed after its dependencies with a CPU type of x86, but it shouldn't be according to how it's header bits have been set. – jmellor Sep 22 '10 at 13:46

1 Answers1

2

You didn't say anything about the kind of assembly. Only the startup assembly determines the bit-ness of the process. The EXE. Any DLL must follow suit.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • This is a detail I forgot to include. The assembly is an executable. – jmellor Sep 22 '10 at 13:35
  • Document how you are sure that it is running in 32-bit mode. And verify that the 64-bit version of .NET is actually installed on your machine. – Hans Passant Sep 22 '10 at 13:37
  • I have both C:\Windows\Microsoft.NET\Framework and Framework64. Both have v2.0.50727 v3.0 v3.5 and v4.0.30319. I'm using taskmgr to verify that the assembly is running in 32bit mode (the process name is appended with *32) – jmellor Sep 23 '10 at 08:46
  • You've eliminated any remaining guess I could have. – Hans Passant Sep 23 '10 at 08:50
  • Thanks for the time and effort though. – jmellor Sep 23 '10 at 09:39
  • 3
    I've just realised I never posted anything on this. I did eventually find the problem by randomly searching the registry and it would be useful to post it in case someone else has the same problem. It turns out something had set the following registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Enable64Bit to 0. I haven't been able to find any documentation on this key doing a quick search so far. However, setting it to 1 and restarting appears to solve my problem. – jmellor Sep 30 '10 at 13:28