The official blog for Windows Server Essentials and Small Business Server support and product group communications.
EPS Team Blogs
[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:
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.
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.