Every several years or so, I undergo a complete system overhaul to keep up with the increasing demands of PC games. One of the components I try not to cut corners on is the GPU. While I was on the NVIDIA track for some time, I decided to pick up an ATI Radeon HD 5970 at Sapphire’s premium price and then some more, due to eBay sharks. (NVIDIA’s Fermi chip is going to be a complete and utter failure, jump ship now.)
Of course, I’m not here to write about the hardware.
After installing the card, I registered at Sapphire for their “gold club” membership; in other words, I registered my card for warranty services. One of the benefits to registration is access to an exclusive tool that allows users to tweak the card’s voltages for (enthusiast) overclocking purposes. After download I ran it a small issue. It doesn’t work at all.
The error baffled me a bit. It was specifically written for the 5970 yet doesn’t work on the 5970. What the hell? Poking around a bit, I discovered the executable was written in a .NET language making troubleshooting much easier.
After disassembling RedLine in Reflector, I noticed two things. First, the error popping up was due to an error being caught by a generic exception handler  in the code. In other words, if anything happened during the initialization of the interface it would cower behind the “not supported” error and shut down. Hardly an accurate message, but at least it isn’t an error with hexadecimal digits.
Notice the program makes use of Windows Event logging? I did. Firing up Event Viewer, I caught a break and found the event generated by the disassembled code above .
VoltDisplayViewModel Failed Instantiation:System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Whoa whoa whoa. This looks familiar. Oh, that’s right… Yahoo made this same mistake a little over a year ago with their WPF-based Yahoo Messenger application. This “troubleshooting signature” is usually indicative of an application being compiled with “Any CPU” mistakenly selected as the target platform. (The target, “Any CPU”, was designed for applications that don’t have a reliance on platform-specific assemblies.) In this case, RedLine is attempting to load a 32-bit (GPU) hardware interoperability assembly into its 64-bit process, which is a big no-no.
Thankfully, the RedLine tool isn’t digitally signed making correction very simple:
- If you have Visual Studio installed, open an instance of the Visual Studio Command Prompt, execute corflags /32BIT+ SapphireRedLine.exe, and be on your way.
- If you’d rather use a hex editor – I recommend XVI32 – simply navigate to file offset 0x218 ($218), change the byte 01 to 03, and save.
Sapphire should feel ashamed for not releasing a quick fix for this by now. It’s been available (and buggy) since November 2009 plus they charge over $700 for the card. Tsk tsk tsk.