MAPI Multithreading Rules

Stephen Griffin - MSFT

24 Sep 2004 2:53 PM

Comments 34

I wrote these rules out while debugging a crash in another MS product:

All threads which use MAPI must call MAPIInitialize before doing any MAPI.
All threads which use MAPI must call MAPIUninitialize before ending.
No thread should ever call MAPIUninitialize if it didn't already call MAPIInitialize.
If MAPI_MULTITHREAD_NOTIFICATIONS is not used, the first thread to call MAPIInitialize should live longer than all other MAPI threads and should be the last to call MAPIUninitialize.

I won't name the app, but it violated all 4 rules.

Known consequences of violating these rules:

MAPI just can't work on a thread that hasn't been initialized. All MAPI calls will fail.
Memory leak.
Either a crash or 'mysterious' errors. Thread A initializes MAPI and starts doing some work. Thread B then calls MAPIUninitialize. If no other thread has initialized MAPI, then MAPI assumes everyone is done with it and cleans up. Depending on the timing, thread A will either crash or start getting failures in MAPI calls.
When MAPI_MULTITHREAD_NOTIFICATIONS is not used, MAPI assumes it can tie the notification thread to the thread on which MAPIInitialize was first called. When this thread goes away, a pointer kept by the notification thread is invalidated, leading to a crash the next time we process a notification.

Exchange, Outlook, MAPI, Gotchas, DevMsgTeam

Comments

David Lowndes

20 Nov 2009 8:57 AM

Someone - who? We know our code and can't think of anything the worker threads do that would automatically get MAPI initialised.

I don't think luck comes into it. We're not being very lucky with this project. ;)

Can you elaborate on the contention we're seeing inside the MAPI calls on our worker threads? Is that normal in any multi-threaded application's heavy use of MAPI?
David Lowndes

23 Nov 2009 6:45 AM

Hi Stephen,

In doubting my sanity over this issue I've subsequently run our gateway under debug with a breakpoint set on _MAPIInitialize@4. It's hit once - from the service initialisation message processing loop. I'm as certain as I can be that there are no per-thread calls to MAPIInitialize. Nevertheless we don't experience any issues making MAPI calls from the worker threads.

Are there perhaps significant differences between the threading/MAPIInitialize requirements of the server version (Exchange 2003) of MAPI and the client version of MAPI?

Also, we've tried explicitly calling MAPIInitialize from the worker threads and while it hasn't caused any issues, it's not had any noticable effect on the contention we see inside MAPI calls. BTW, the parallel stacks debugging view in VS2010 is very illuminating for these situations.
Stephen Griffin - MSFT

23 Nov 2009 7:02 AM

The contention has nothing to do with initializing MAPI (though you should still initialize it on every thread). The contention is because many operations in MAPI and in the ems providers are serialized.
Renald

18 Dec 2009 7:25 AM

Hi Stephen,

First, good job with this blog.

I have a problem with my MAPI program (writen in C++.NET).

My program is a service, so I initialize MAPI with MAPI_NO_COINIT and MAPI_NT_SERVICE flags.

But MAPIInitialize returns me the error 0x80004005.

I wrote a second program (console) that make a MAPIInitialize but with MAPI_NO_COINIT flag only.

MAPI has initialized with no problem.

Do you know if it could be a problem of multi processor?

And if I remove the flag MAPI_NT_SERVICE in my service program, what could be the consequently?

Environment (new computer, office installed only):

XP SP2

Office 2003 v11.0.8173.0

Administrator of my computer

Thank you

Renald