Introduction
We use a Windows Server-based telephone system (
Altigen pbx), which in my experience has been a great system for us. With each new release of the software, they have added new features and as a result the various software clients all need to be updated when the Server is updated.
One of these clients is called AltiView, and it provides a nice Windows interface for end users to initiate calls, listen to voicemail, see caller id information, and a host of other things. In this latest release the name changed to MaxCommunicator, with an almost identical feature set but now written on the .Net framework. The one major feature change for me: it will no longer work on my Vista x64 computer
I was initially annoyed when I discovered that x64 compatibility was gone. Then I became really annoyed when the developers responded with a one line answer: 'Our applications don't support 64-bit operating systems'. The annoyance factor was magnified by the fact that the other clients I installed all worked fine, just not MaxCommunicator. Fuel to the fire was the knowledge that of the 125 people using the software in our offices, only I would be denied the desktop client...because only I run Vista x64.
Diagnosis Process
The installation of the program completes without a hitch. The program starts just fine, and displays the login panel where I would normally type my phone extension and password. Everything seems ok until I click 'Login' -- then I receive an error message that says the program has detected an installation error.
I tried all the usual stuff. Uninstall, clean registry, set Compatibility Mode for the executable, etc, etc. Nothing would let me past that error. My next thought was that maybe something was missing in the Registry. If you have never used RegMon from SysInternals, then you have never used one of the most handy utilities for diagnosing Windows problems like this. RegMon is now part of Process Monitor, which is available
here.
Using Process Monitor I was able to see every Registry request the program was making and the results. I thought I was getting somewhere when I saw a fleet of Registry requests for keys that did not exist in my Registry. So I promptly fired up a Vmware test machine and installed the software so I could determine what should be in those keys. Unfortunately, even in the 32-bit install the keys were not there. Dead End.
Back to Process Monitor, and I noticed file activity for the application. It was writing a log file, which gave me my first big clue. There was a message in the log that read:
2009-07-06 19:48:58,366[4268]ERROR i:\IcCenter\MaxClients\MaxCommunicator\BusinessClassCollection\ClientAutoUpgrade.cs [155] - AutoUpgrade Throw Exception. Message: Retrieving the COM class factory for component with CLSID {5FCA6A47-CE12-45F5-89AA-C79D804E9F68} failed due to the following error: 800700c1.
A few things I noticed:
· The application is written in C#
· ClientAutoUpgrade seems to be the culprit
· We have a Class Id
· We have a googleable error message about the 'COM class factory' and '800700c1'
The C# bit was my first real indication I was dealing with a .Net application. ClientAutoUpgrade wound up being important because in the application directory is a DLL with a similar name. The ClassId gives me something else to check for in the Registry. And finally, knowing what to search for in Google is half the battle.
With this knowledge I began my search. I read dozens of unrelated and semi-related web pages and posts, but none of them hit the mark. After a while though, I was able to detect a bit of a pattern. Running a program on x64 is not really a problem unless it involves hardware drivers not written for x64. The program just runs in 32-bit emulation, officially known as Windows On Windows mode (WOW64). This application does not support x64, so obviously it should be running in WOW64 - right?
Well, take a look at my Task Manager:
You will notice that there is NOT a *32 next to MaxCommunicator.exe. That means it actually IS a 64-bit compatible application. Someone should tell the developer! So at this point my problem has actually changed: Now I have a 64-bit application that will not run on an x64 operating system.
Back to Google again, looking for reasons why a 64-bit app might fail in Vista x64. A number of false positives, before I came across a developer complaining about his application failing to transfer files from one system to another, but only on Windows XP x64. Digging through the thread the developer finally mentioned that the actual transfer was being handled by a DLL he had built years earlier. And 32-bit DLLs cannot be accessed by a .Net app running in x64 mode.
Bingo. I bet that DLL from the error message a while back is a 32-bit DLL.
Resolution Process
Ok, now my search criteria have changed again, because my problem has changed again. Assuming I am correct about the DLL being 32-bit, now I need to learn how to force a 64-bit .Net application to run in 32-bit mode so that it will be able to use 32-bit DLLs. Back to Google, and I learn fairly quickly that the answer is simple: When compiling the solution in Visual Studio, instead of targeting ANY operating system, target 32-bit only. An answer that requires me to have the source code is not really an answer at all. Dead End.
A few more tweaks of my search criteria and I finally discover that the .Net SDK includes a tool that can change the 32-bit flag in a compiled executable or DLL. No source required! Now we are talking.
I use the tool named CorFlags.exe with the flag /32BIT+ on every app and DLL in the application's directory. When I tried to set the flag on the AutoUpdate.dll I had mentioned earlier, I received an error that it did not have a managed header. So it is not .Net, lending further credence to the assumption that it is the 32-bit DLL causing my problem. For whatever reason, they chose to not rewrite this DLL...
Everything should have been fine, now that I have ensured that all of the .Net modules have the 32-bit flag set. Of course, as soon as you start thinking like that it is almost certain that some other problem will be found. So, it came as no surprise when the application would not load AT ALL after changing all the 32-bit flags. Instead, it went straight to the 'Windows has detected an error' dialog.
Fearing the worst -- the worst being unable to screen my calls for the next XX months until the developer decided to officially support x64 -- I finally got a little lucky. I decided to go to the application's executable and try to compatibility mode again. When I opened the properties I discovered that it was still in Compatibility Mode. I turned that off and like magic, everything worked fine. Evidently Microsoft decided that applications running in 32-bit only mode should not be compatible with Compatibility Mode.
Long, long story short -- -CorFlags.exe saved the day for me. If you hung in this long, hopefully it can save you too.
Conclusion
Back to the original remarks about the developer in this instance. If I had a commercial application and learned that the new release was actually a step backwards in terms of compatibility -- and with that step backwards a decrease in my potential user base -- I would be jumping through hoops to get the issue resolved. Here I received nothing but a cursory brush-off.
If an end-user, without the source code or any inside knowledge of the program and how it works, can fix it -- then how hard could/should it be for the actual developer?