Have you ever had an application that seemed to initially run fine under Windows x64, only to have it crash or complain when performing a certain function inside the app? If you’ve run into this problem, take heart because the fix is really simple.
But first, it’s helpful to understand what happens when you run an application under 64-bit Windows. Some applications and libraries (DLLs) are compiled in such a way that they can run either as native 64-bit or 32-bit mode. Other applications and DLLs, however, can only run as 32-bit.
Let’s say you have an application that easily runs as a 64-bit app under Windows 2008 R2 (which is a 64-bit OS). No problem, right? But what if that app makes a call to a Crystal Reports DLL that is compiled only as a 32-bit DLL? Trouble! That’s what happens! The application will not be able to find the DLL. As far as the app is concerned, the DLL doesn’t exist.
To understand why, we must understand how Windows separates 32 and 64-bit components. Windows x64 stores 32-bit DLLs in the Windows\SysWoW64 folder, while 64-bit DLLs go in the Windows\System32 folder. That seems backwards, doesn’t it? But it gets even more counter-intuitive. When a 32-bit mode application runs under Windows x64 and wants a DLL from “c:\windows\system32”, Windows will “lie” to the app and give it the DLL from C:\windows\syswow64!
The flipside of this redirection scheme is that 64-bit apps are affected as well. 64-bit applications cannot see or access the Windows\SysWoW64 folder. They can only see Windows\System32. If an application installer places a 32-bit DLL in Windows\SysWoW64, then later a 64-bit application tries to call that DLL, it will simply fail because, to the application, that DLL doesn’t exist.
But what if we get sneaky and copy that 32-bit DLL to the System32 folder? Our 64-bit app will find the DLL, but it will not be able to load it into its memory space (For a technical explanation why, see Why can’t you thunk between 32-bit and 64-bit Windows?). Once again, the app will crash or yield an error.
So what is the solution? We just have to get the 64-bit app to run as a 32-bit application. This will allow the app to see the 32-bit DLLs in the Windows\SysWoW64 folder and load them into its memory space. We will lose some of the benefits of 64-bit execution, but at least the app will work properly. And fortunately, we don’t have to get the vendor to send us a recompiled executable. We can force the app to run as a 32-bit app by changing the execution headers using the Microsoft CorFlags utility. All you have to do is install the Microsoft Windows SDK and grab CorFlags.exe from the Bin folder of the SDK program files directory.
Then all you have to do is run:
CorFlags /32BIT+ application.exe
where application.exe is the application you want to force to run as 32-bit. The next time you execute the application, Windows will see the new header and will execute it as a 32-bit application.Tags: 32-bit, 64-bit, dll, dotnet, windows-server, windows-server-2008, windows-server-2012, windows-server-2016