"Mark McGinty" wrote in message
...
Thanks for the informative reply, Ken, see responses inline...


"Ken Slovak - [MVP - Outlook]" wrote in message
...
Is the background process doing anything with the Outlook object model?

Other than creating/deleting/locating/changing contact, task and
appointment items, no not especially. :-)

Outlook is designed so that all accesses to the object model must be on
the main thread and especially with VB 6 if a background thread calls
into the object model that will crash Outlook (more with Outlook 2007) or
hang it (more with Outlook 2003 or earlier). Could something like that be
the problem?

It hasn't been a problem until Outlook 2007 came along... OOM isn't
thread-safe within Outlook's process space? I could understand (and even
expect) individual objects being non-thread-safe, but the entire model
needs to execute in a single thread? Is that documented anywhere?

Out of curiosity I added a call to GetCurrentThreadID to my debugging
output. Apparently all OOM events *and* all of my timer controls' Timer
events -- they all execute on the same thread! My async XMLHttpRequest
calls must surely cause creation of a new thread, but I poll the
readystate of that object (it's event is unreliable) so even my accesses
to that *should* execute on Outlook's single chosen thread...


I do a lot of background processing with many of my addins and haven't
see the hang problem you describe unless the object model is being used
there.

I have seen and heard of quite a few hang problems with Outlook 2007
related to working with the object model even on the main thread when
typing in the body of an email. What I haven't see are any clean repros
(that sort of thing never yet has happened here on any of my Office 2007
setups for example) or good explanations of why it's happening.

Hmm, I just might be able to create that nice clean repro...

This is getting very interesting.

More to follow...


-Mark

I compiled our AddIn with debugging info, and downloaded all the debugging
symbols for the system, to facilitate useful debugging with VS 2005, of
Outlook's process after it hung. This helped me to definitively isolate the
problem construct, in only a few painful but bearable hours. :-)

It appears that the problem -- or, at least, one manifestation of it -- is
caused by calling DoEvents, particularly in a loop (which, of course,
substantially ups the odds of it being called at exactly the wrong time.)

My Addin calls DoEvents 103 times, I've made a point of calling it in
practically every single loop, to minimize the UI impact of background
processing/make user cancellation possible. I guess we'll have to forego
that nicety under Outlook 2007.

As for the threadedness of background processing, I found (by outputting the
ThreadID of the current thread in every debug output) that every single
thing my AddIn does, is always called on the same thread, be it OOM events,
timer events on hidden forms -- everything. I can't say it's impossible in
VB6 to execute [in-proc] background processing on some other thread, but
from what I've seen it surely doesn't happen by accident. (Use of out-proc
COM servers excepted.)

In any case, OOM object access was not implicated in any of the AddIn's
post-hang callstacks I trapped into -- in this case all of them were
enumerating XML object collections. (Most of the loops that do so in this
code are fairly tight, which may serve to explain the behavior upon which my
observations were based.)

Unfortunately I don't have any simple, clean repro code to share [yet], but
I was able to reproduce the condition consistently, like ringing a bell,
running our [arguably somewhat convoluted] AddIn code. I will try to pare
it down to something simple enough to publish here, as time permits.


-Mark






Some theories are that too many RSS feeds can be implicated, background
indexing of Outlook items for WDS is another possibility, as is a setting
for doing send/receives with too short an interval.

I've had reports from members of the Outlook product group that the same
thing has happened with them with no addins running, so while this may
not help it may not be the fault of your addin at all.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Mark McGinty" wrote in message
...
Our VB6 AddIn uses timers on an invisible form to drive background
processing -- a good deal of which involves MSXML.XMLHttpRequest, called
asynchronously.

The background processing itself doesn't cause any problems, I have had
a virtual running for days with a very short interval for background
tasks, and with multiple inspectors left open -- it has yet to hang. On
an identical virtual, while typing in an email body as I normaly do when
composing, I have seen Outlook hang numerous times. For all
occurrences, background processing was underway when it hung.

Google returns countless reports of a similar nature, but I have yet to
see mention of a solution, nor even an exact cause.

Has anyone else seen anything similar? If so, any resolution? I keep
seeing statements by various MVPs about "compatible" AddIns (some even
suggest using only AddIns developed by Microsoft -- which is pure BS if
you ask me.) Is there any spec for Outlook 2007 AddIn compatibility?
Any idea what the 2007 email editor is doing that is so intolerant of
AddIns doing things behind the scenes?


TIA,
Mark

btw, yes this is somewhat a repost of an earlier question, I wanted the
subject to more accurately reflect the problem.