Case in the Corner Series: x64 Framework not working

Case in the Corner Series: x64 Framework not working

  • Comments 2
  • Likes

[Today’s post comes to us courtesy of Damian Leibaschoff from Commercial Technical Support]

When this SBS 2008 call first came in, the main issue was the Console was not launching (it was actually crashing). Soon we realized that a lot of other services and programs were not able to start successfully on this server. These included most of the Exchange services, the Windows SBS Manager service and almost all of the SBS wizards to mention a few of the issues

At first we thought it could have been related to IPv6 being misconfigured ( Issues After Disabling IPv6 on Your NIC on SBS 2008) but we soon ruled that out.

The exception on every failure was always the same:

Exception type: System.BadImageFormatException

We decided to continue using the console.exe process to investigate the crashes.

Process Monitor showed the following output:

clip_image002

Right on the first page we noticed something odd, our Console is a 64-bit Framework application, yet the 32-bit libraries were being loaded.

When we launched the console under a debugger, we noticed the same strange behavior, it was loading the wrong bitness for the framework assemblies:

CommandLine: "C:\Program Files\Windows Small Business Server\Bin\console.exe"
Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00000000`51090000 00000000`515d8000 Console.exe
ModLoad: 00000000`77900000 00000000`77a86000 ntdll.dll
ModLoad: 00000000`77ac0000 00000000`77c20000 ntdll32.dll
ModLoad: 00000000`75770000 00000000`757b5000 C:\Windows\system32\wow64.dll
ModLoad: 00000000`75720000 00000000`7576e000 C:\Windows\system32\wow64win.dll
ModLoad: 00000000`75a70000 00000000`75a79000 C:\Windows\system32\wow64cpu.dll
(1c78.1fd8): Break instruction exception - code 80000003 (first chance)
ntdll!DbgBreakPoint:
00000000`77946060 cc int 3
0:000> g
ModLoad: 00000000`777d0000 00000000`778fd000 WOW64_IMAGE_SECTION
ModLoad: 00000000`75bf0000 00000000`75d00000 WOW64_IMAGE_SECTION
ModLoad: 00000000`777d0000 00000000`778fd000 NOT_AN_IMAGE
ModLoad: 00000000`77700000 00000000`777cd000 NOT_AN_IMAGE
ModLoad: 00000000`73070000 00000000`730ba000 C:\Windows\SysWOW64\mscoree.dll
ModLoad: 00000000`75bf0000 00000000`75d00000 C:\Windows\syswow64\KERNEL32.dll

We ruled out file corruption, especially since most other 64-bit Framework consumers were failing. At this point we started looking at what can cause the Framework to act like this.

We found our answer on a registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Enable64Bit

The default value for this key is 1, yet on this case it was set to 0, forcing framework applications to run in a 32-bit environment.

To correct this, we changed the value back to 1 and rebooted, we could also have used the native tool that configures this:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe set64
loading kernel32...done.
retrieved GetComPlusPackageInstallStatus entry point
retrieved SetComPlusPackageInstallStatus entry point
Setting status to: 0x00000001
SUCCESS

As expected, all the applications started working as designed after correcting this.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Comments
  • What caused this bit to be set to 0 in the first place? Was it a user messing around? or was it due to a patch or software that had been installed?

  • Partner working on the server did not know what had been done to the machine. There was no evidence of a third party application so someone trying to manually get something working was the main suspect.