After releasing TEO 2.0 on Monday, hundreds of people rushed to the site to download the software. This may not seem like a lot but to a small one person shareware operation, it is. I love the fact that it is so popular, but unfortunately like all software, not every install goes as smoothly as it does for most. The abundance of support questions have unfortunately slowed my response times a bit so I’ll need to get back on track. (I do still have a 40 hour a week day job, remember.)
Some of you may have read on Marc Orchant’s web log about the beta issues I worked with him on. Unfortunately it turned out to be an underlying problem with the Tablet PC Ink API’s and not my software at all. He’s not the only one that has experienced this problem. Although uncommon, about four of my users have reported errors that looked like TEO problems but turned out to be problems in the new Tablet PC 2005 RealTimeStylus API’s.
There have also been other problems such as users trying to enter the new serial numbers into TEO 2.0 betas or RC’s which doesn’t work. This is my fault. I probably should have been clearer about that.
However, there are some problems that I just can’t even figure out. For the last three days or so I worked with a customer that could not load TEO no matter what. No log files, no error messages, nothing. Creating the log file is the first thing TEO does so this really concerned me. Fortunately, the customer was very technically skilled so I didn’t have to “hold back” when diagnosing the problem. We tried everything… fuslogvw, FileMon, RegMon, lots of gacutil and ngen calls, registry manipulation, etc. Even now I have no idea what the problem on his machine was. The COM shim was just not being loaded by Outlook at all. It was the weirdest thing. His security settings were fine, other managed add ins loaded fine. When we ran FileMon and RegMon, Outlook would load the COM registration information from the registry, but would never access the file!
It’s like Outlook knew there was an add in to load, knew how to add it, but never even tried. A VBScript with a single CreateObject() statement succeeded, but not Outlook. Weird.
It was then that I got the idea to have him log off and back onto the machine as a different user. Worked fine! What’s going on here? By this point, we had been going back and forth for three days and I couldn’t even believe that this customer was still even willing to use TEO much less talk to me. He was happy with the support effort that I put forth and the next day reported to me that a “Detect and Repair” in Outlook fixed the problem.
Lesson learned anyway… from now on I am not going to hesitate to ask a customer to repair their Office installation if they are experiencing strange problems like this.