Hi all!
Something broke in the last release of our COM-addin (written in Delphi
7 using Redemption). It no longer works with Outlook XP (aka 2002).
There are absolutely no problems with the same addin under Outlook 2000
and Outlook 2003.

The symptoms of the breakage are sudden exits or hangs on certain
operations. The behaviour is totally reproducable (i.e. it's always the
same steps that lead to a crash or hang) but I haven't been able to
figure out how those operations should lead to such behaviour or to
make out a common pattern yet. I've got OutputDebugString statements on
pretty much every second line in my code by now, including the
exception handlers, but, when comparing these logs to those of the same
operations performed on an Outlook 2003 installation, there is
absolutely nothing indicating a failure or malfunction right up until
the point where Outlook just suddenly exits or simply freezes.

Are there any known gotchas with Outlook XP that I could have run into?
Especially any that do not apply to Outlook 2000 and 2003? If so, where
can I find more information about this?

I've got a slight suspicion that it might have to do with exception
handling because none of the OutputDebugStrings in the exception
handlers ever seem to fire even though I feel there *must* be something
going wrong... then again I already went through my code and made sure
that no exceptions ever bubble up to the surface a year ago. Everything
is handled already (unless of course there's something triggering new
exceptions inside the exception handlers - but why should that differ
between different versions of Outlook?).

Help?

Cheers,

Oliver

Oliver Giesen wrote:

The symptoms of the breakage are sudden exits or hangs on certain
operations.

Some more bits of information that might (or might not) be useful:

* In the case of the sudden exits, my addin receives no BeginShutdown
or Disconnection events (_IDTExtensibility2) nor a Quit event from the
application object nor do the various explorers or inspectors trigger
any Close events but code in unit finalization sections apparently
still gets called alright.

* A new suspicion: I discovered that I can also trigger the crash by
repeating certain operations several times, e.g. opening and closing a
dialog that is part of my addin four times. Looks like a memory issue
to me. However, I have already used various mem checking tools and
there appear to be no leaks. I'm also using the FastMM replacement
memory manager which can be run in debug mode and it's also not
reporting any memory management issues...

any more ideas?


Cheers,

Oliver

Do you use the MAPIUtils object from Redemption?
If so take a look at the Redemption FAQ

http://www.dimastr.com/redemption/faq.htm

There are some issues mentioned(and workarounds) when using MAPIUtils in OutlookXP.

Ralf

Ralf Jansen wrote:

Do you use the MAPIUtils object from Redemption?
If so take a look at the Redemption FAQ

http://www.dimastr.com/redemption/faq.htm

There are some issues mentioned(and workarounds) when using MAPIUtils
in OutlookXP.

You are probably thinking about the notes about having to call
MAPIUtils.Cleanup, aren't you? I have by now talked to Dmitry
(Redemption's author) and he told me that actually as of Redemption 4.0
this is no longer necessary at all...


However, here's another major update to the story:

I have by now discovered that the issue appears to have been fixed by
Microsoft in Office XP Service Pack 3. If I update Outlook to that
service pack, the crashes and freezes go away. The trouble is that the
customer I'm doing this for cannot upgrade his workstations in the
short term due to internal policy issues (there's 1000 workstations and
they're running critical Access applications). In other words I need to
find a way to work around the bug. I have already tried to determine
which particular hotfix addressed this in the hopes that either the
technical description would give me some hints as to what to avoid or
at least that maybe installing a highly-focused hotfix would be more
acceptable for the customer than doing the full Office update.
Unfortunately none of the pre-SP3 hotfixes that are available as
standalone downloads seems to be the one I'm looking for. So it must be
something that is only available as part of SP3 itself...

Any ideas? The closest I've found so far was KB891298 which also speaks
of unexpected exits but the rest of the description does not apply at
all to my situation (i.e. the problem is not specific to running under
Terminal Services and I'm not opening or closing files either).

Cheers,

Oliver

You are probably thinking about the notes about having to call
MAPIUtils.Cleanup, aren't you? I have by now talked to Dmitry
(Redemption's author) and he told me that actually as of Redemption 4.0
this is no longer necessary at all...


My concern was the last point in the FAQ.
Does 'no longer necessary' includes that point?
That would be great. I have multiple threads with mixed Appartments (STA,MTA) running in my Outlook Plugin.
And trying to use just one Instance of MAPIUtils in them makes the hole thing somewhat fragile and easy to break when refactoring/extending.

Any ideas? The closest I've found so far was KB891298 which also speaks
of unexpected exits but the rest of the description does not apply at
all to my situation (i.e. the problem is not specific to running under
Terminal Services and I'm not opening or closing files either).

Cheers,

Oliver

Sorry, Oliver. Coping with the plethora of Microsofts KB's is far beyond my abilities.
At this point i would open a support case and let them find it.

Ralf

try n use marshal.releasecomobject to release the objects having ref. to
explorer/inspectors etc.
and then gc.collect

"Oliver Giesen" wrote:

Oliver Giesen wrote:

The symptoms of the breakage are sudden exits or hangs on certain
operations.

Some more bits of information that might (or might not) be useful:

* In the case of the sudden exits, my addin receives no BeginShutdown
or Disconnection events (_IDTExtensibility2) nor a Quit event from the
application object nor do the various explorers or inspectors trigger
any Close events but code in unit finalization sections apparently
still gets called alright.

* A new suspicion: I discovered that I can also trigger the crash by
repeating certain operations several times, e.g. opening and closing a
dialog that is part of my addin four times. Looks like a memory issue
to me. However, I have already used various mem checking tools and
there appear to be no leaks. I'm also using the FastMM replacement
memory manager which can be run in debug mode and it's also not
reporting any memory management issues...

any more ideas?


Cheers,

Oliver