Rather than getting lost in a lot of technical definition and supposition,
I'll begin with a description of my repro, what to do with it, and the
visible difference between OL2007 and previous versions. (I think it will be
easier to demonstrate first, than to try to explain.)

This repro is an AddIn written in VB6, with a modeless form that uses a
timer object to perform [contrived] background processing on an interval,
set by the user, in milliseconds. Each time the timer event fires, it
executes a loop, the number of iterations for which is also set by the user.
(Note 1)

The repro AddIn is flagged to load on next startup only. OL must not be
running when you register the DLL. The repro's form will be displayed when
OL is started one time only. The form can also be shown by disconnecting
and then connecting the AddIn, using the builtin facility. (Note 2)

When the repro's form is first displayed, its background process launch
timer is disabled. Clicking the start button enables this timer; as it
runs, the status of background processing is displayed in the form, cycling
between "running" and "idle". While status is "running" the processing loop
is performing it's [useless and contrived] "work"; when the loop ends,
status changes to "idle", and it waits for the next timer event to fire.
(Note 3) Click the cancel button to disable the timer, to make background
processing stop. (Addiional detail about status transitions and event
firings is sent to the debugging port.)

If the "Call DoEvents in loop" checkbox is checked, the repro [intuitively]
calls DoEvents once each iteration of the loop; if the checkbox is clear it
[also intuitively] skips that call. ***This is key to proving-out the cause
of the problem in OL2007. When the checkbox is clear, OL2007 will not hang;
when it is checked, and you are typing in an email while the background
processing is running, OL2007 will hang.

Steps to reproduce OL2007 hanging:

1. With OL not running, register the repro DLL using regsvr32.exe.
2. Start OL -- the repro's form should display for one Outlook session only.
(Use the COM AddIns management dialog to disconnect and then connect the
AddIn, to show the form again in the same OL session.)
2a. After closing the COM AddIns dialog [and all of its modal parents] the
repro's [modeless] form will be displayed -- because it is modeless, it may
get buried behind OL, but it has a task bar icon, that will be in Outlook's
group, if grouping is active.
3. Create a new email, click the Start button in the repro's form, and then
start typing in the new email.
3a. Holding down a key and letting it repreat will not cause OL2007 to hang,
because OL2007 suspends the AddIn's execution until the key is released.
3b. In fact, typing very rapidly (e.g., bouncing the same key as fast as you
can) will not cause OL to hang straight away -- UI activity in OL2007
suspends AddIn processing (as can be seen using a debugging port reader, the
duration of each processing loop is output there -- notice that it takes
longer to complete if you hold a key for several seconds while status is
"running".)
3c. Position the repro's form so it is visible while you are typing; if you
can see its status transitioning between "idle" and "running" as you are
typing, it should not take very long for OL 2007 to hang.

The "Call DoEvents in loop" checkbox is checked by default when the form
loads. If the test above is performed with the checkbox cleared, the email
composition window (in fact, all of OL) will seem frozen while background
processing is running; when it completes, all user input that occurred in
the [apparently] frozen UI plays out almost instantaneously. This behavior
tends to be unsettling to users -- thus the reason for calling DoEvents in
the first place. However, hanging OL in mid-composition is more than
unsettling, so avoiding calls to DoEvents under OL2007 seems the lesser of
two evils.

The repro DLL was built on an OL2003 system, so it will work in either 2003
or 2007 -- though it will not hang OL2003. Under OL2003, native OL code and
AddIns seem to run without preference for one or the other, i.e., UI
activity does NOT suspend AddIn processing. (Logically it must slow the
AddIn down infantessimally, but with whole-second accuracy of duration
timing, it's imperceptible using this repro.) In OL2003, an AddIn can yield
the processor to permit OL's UI to be updated, and then continue safely on
its merry way. (This is EXACTLY as it should be.)

Conversely, under OL2007, preference is apparently given to OL UI
processing. As is stated multiple times above, OL2007 suspends AddIn
processing while the user interacts with its UI. Clearly the mechanism that
does this is fatally flawed, and causes OL2007 to hang.

Note that it is NOT the AddIn that causes OL2007 to hang! It merely gives
OL2007 enough [proverbial] rope to hang itself. The tragedy to me is that
this new OL2007 behavior is unnecessary when using well-written AddIns
(which will often be callers of DoEvents.) It's crappy AddIns that block
OL's UI for inordinate lengths of time that no-doubt prompted this change --
how appropriate that well-behaved AddIns get the shaft... NOT! It's a
travesty as well, because even this ill-considered mechanism does not
overcome a tight loop, OL2007 is just as unresponsive as earlier versions.
So basically the only thing it accomplishes is breaking countless VB6
AddIns.

The culprit seems to be an Office-specific function within the VB6
runtime -- which obviously predates OL2007, but still... Perhaps they
should've provided an Office object model method to do the equivilent of
DoEvents, rather than build Office-specific behavior into the VB6 runtime --
this would've allowed them to update that method along with Office.

As is, as of Office 2007, the VB6 runtime is left with a very dangerous and
detrimental call. Perhaps it's intended to force developers to quit using
VB6, but in reality it will force us to release updated VB6-based versions
of existing AddIns, because this problem is too severe to force users to
deal with it long enough to port code to a supported language/compiler.

All sources are attached. Any comments are welcome.


From what I have found, mine is the first repro of this widely reported
problem, as well as the first to identify the problem. If you republish or
otherwise distribute any part of this, please give appropriate credit.


-Mark McGinty




(Note 1) The code inside the loop concatenates a short string to itself
until the length of the string exceeds an arbitrary length, then it
truncates the string back to a short one and does it again. (In other
words, it exercises string object memory allocation. It is unremarkable,
but it is such that it cannot be optimized away as an invariant loop. Also
it does not touch OOM in any way, eliminating that as source of the
problem.)

(Note 2) When you connect the AddIn it loads a form, and then tries to make
that [modeless] form visible -- which initially fails because the built-in
COM AddIn dialog is modal. It eats the error, and retries every 3/4 seconds
(using another timer) until it succeeds. (I agree it's quick and dirty, not
suggested for use in useful AddIns.)

(Note 3) If the timer fires while the loop is still running, the timer's
event handler is coded to exit. However, in testing, the timer never fired
while the loop was running (even though the duration of the loop exceeded
the timer's interval.)