It's not really how any addins connect with Outlook, there's only one way to
do that. It's that some addins insist on accessing the Outlook object model
from a background thread. That's the problem, despite many years and KB
articles from MS saying not to do that.
I first discovered the problem in relation to the ITunes Calendar Synch
addin, which after synching would hang or crash Outlook and get Companion
blamed. In working with the top MAPI escalation engineer at MS we discovered
that Apple was doing that and that due to how the VB6 runtime is, that if
any VB6 addin is running when that background access occurs the top VB6
addin on the call stack gets the call and crashes the VB6 runtime, therefore
getting the VB6 addin blamed for the mess caused by some other code.
Even with Apple, where I worked with the dev for a couple of months to fix
all of their problems, they've backslid in some later versions and done the
same thing again.
MS usually doesn't do that sort of thing with the code they supply, but it's
hard to be positive. My initial guess would be the PDFMOutlook addin, which
in various incarnations has been know to do bad things to Outlook. However,
a systematic approach is best when troubleshooting.
What I'd do is to disable completely all the addins running, including
Companion. Repeat the steps needed to get the crash and make sure no crash
is happening with no addins. Then re-enable Companion. Test again. Repeat
until you start having problems again, then you disable that last addin and
verify the problems have stopped. That should isolate the culprit.
I've seen many addins doing this, so the next one you load may have the same
problems. You just never know.
When I was initially investigating this I contacted some friends who also
have VB6 addins out there, such as the owner of SperrySoftware and their
addins all also had the same problems when a miscreant addin was running, so
you just happened to run into the problem with Companion, it could very well
have been some other addin you were using that got the blame if it was
written using VB6.
Version 2.0 of Companion is the latest version, and support was correct that
there's nothing WinZip can do to prevent or workaround the problem, since
the crash is occurring in the VB6 runtime outside of Companion's executing
code or error handling. About the only thing that could be done would be to
completely rewrite the addin using C++ or managed code. And then the crash
or hang would still occur, it just wouldn't get blamed on that addin but
some other one.