crash dump report

> I have seen something similar to this before when a thread started by
> a DLL that Dolphin had loaded (in this case directly, but that need
> not necessarily be the case) was crashing. In that case it was the
> HTML help OCX, and it was crashing when switching away from a dolphin
> deployment. It turned out that it had not been shut down properly,
> and I imagine that it hooks application activation/deactivation in
> some way. This was particularly likely to show up when a particular
> virtual window manager was used.
>
> One possibility to consider is that a definitely a foreign thread has
> "successfully" called back into Dolphin. A callback on another thread
> might occur, for example, by passing out an unmarshalled COM
> interface pointer to something which then holds a ref. to it and uses
> it from another thread. The rules, and system infrastructure, of COM
> help to guard against this happenning, but it is possible to do it.
> Also a standard callback object could be passed to an API which
> captures it and calls it from another thread. The VM guards against
> incoming calls from foreign threads and marshals them onto the main
> thread (an action which might cause a deadlock, but there is little
> other choice), so I can't quite see how it would happen, but it is
> worth being aware of.
>
> By far the most likely explanation would be either the first, i.e.
> that a thread has been started by a component that Dolphin is using
> and is crashing, or that some overlapped call is crashing.