Add-in threading issue causes Outlook to crash or hang

If you have written an Outlook add-in with Visual Basic 6.0 and you are getting new and unexpected reports of it crashing, you might want to ask the user whether the Apple ITunes add-in is also installed. According to Outlook MVP Ken Slovak, the ITunes add-in, which synchronizes the Outlook calendar with an IPod, can cause Outlook 2007 to crash and Outlook 2003 to hang in a way that makes it look like another VB6 add-in is responsible, because of a threading issue.

UPDATE: As of 18 Jan 2008, Apple has released a new version of the iTunes add-in that does not produce this behavior.

The Microsoft support engineer whom Ken has been working with explained that Outlook was designed with the assumption that all calls to the Outlook object model are on thread 0. Some other often used DLLs also make that assumption, including the VB6 runtime (MSVBVM60.DLL), which is used in many of the Outlook add-ins currently available.
 
The problem apparently occurs because the Apple add-in sets up a new thread using a named pipe to do the calendar synching but neglects to marshal the thread back to thread 0 for any calls to the Outlook object model. Instead, it calls into the object model instead on thread 7. This lack of a proxying back to thread 0 then sets Outlook to call into MSVBVM60 to pass along any events that have fired due to the object model access (for example the ItemLoad event available only in Outlook 2007, which fires on every object model access to any Outlook item). This then crashes Outlook due to the threading. The stack is read by Watson and whatever is at the bottom of the stack gets blamed for the crash, usually MSVBVM60 but also Kernel32 on Vista. The next time Outlooks starts up, whichever addin was listed lowest in the stack is then blamed for the crash.
 
If no VB6 addin is running, Outlook doesn't immediately crash. Instead, it becomes unstable and might crash at any later time, or it might just get hung in a deadlock between threads, something that won't happen if all calls to the object model are called in thread 0.
 
According to Ken, there is no possible defensive programming that an add-in developer can do to prevent another add-in from causing this problem. The problem add-in must change its code to prevent the problem from occurring. Microsoft is in touch with Apple about the problem with the ITunes add-in. However, any other vendor whose add-in takes the same approach to threading will cause the same problem, which means that this is a vendor-by-vendor problem that will have to be addressed each time a problem add-in is discovered.