Share via

Do You Feel Lucky? Multithreading the Profile API

  • Article

I picked up a case a few weeks ago that had a simple question in it. "Are MAPI's profile APIs thread safe?" My answer, of course, was "As far as I know - why do you ask?". The reason they asked was because they had built a framework to encapsulate all of their MAPI operations (a very good idea) and they were seeing "issues" when they ran the profile configuration portion of that framework through their multithreaded test harness.

At first, I had a little trouble pinning down what they meant by "issues" - did they mean hangs? Crashes? Random error codes? Actually - it was all of the above. I got some dumps and traces from them and found 2-3 distinct problems with the way MAPI and some of the providers behave in an non thread safe manner during profile configuration/deletion. When I started running my own tests, I found a few more.

Now - I've always understood MAPI and the providers we ship to be thread safe. Sure, there are the occasional issues, but we usually can fix them. We go to a lot of trouble to make sure MAPI behaves correctly across multiple threads. But apparently all of this work, and all of our testing, was under the assumption that the profiles had already been created. I dug back through records of cases I had worked as well as bugs which have been filed against MAPI and found only one case where someone had configured profiles from multiple threads. And on examining that case, I saw that it was from the days before we routinely had multiple processors. Most of the threading issues I was seeing would be much harder to reproduce on a single processor.

I took the list of issues we found back to development to see what they thought we should do about this. The issues we found were in both Outlook and Exchange's implementation of MAPI (they predate the split), meaning we had a long road ahead of us if we started fixing the problems. And even if we assume we fixed every issue we found, we were certain to find that those issues were hiding other, nastier issues.

So we decided that the best course of action here would be to declare MAPI's profile API's not to be thread safe. All MAPI profile configuration should be serialized. This applies to both Exchange and Outlook's implementations of MAPI and all versions, including the MAPI download.

Here are the APIs you'll need to serialize as a MAPI client:

Comments

  • Anonymous
    June 30, 2008
    We're using the MAPI API to create msg files from a C# web service; and we're using redemption to access MAPI without raising the security warnings.  It runs fine for a long time but then randomly fails. Could this be the threading issue that you describe above?  We've rebuild the account profile which fixed the problem the last time it occured. Any advice will be much appreciated.

  • Anonymous
    June 30, 2008
    Doubtful. But you should take Redemption issues to the maker of Redemption.

  • Anonymous
    April 02, 2009
    is it also unsafe to use the profile api from multiple exe files at the same time? what i have is a program that do the mapi work as a separate process and not threads. that program begins with creating a temporary profile and onced its finished it cleans up the profile after itself.

  • Anonymous
    April 02, 2009
    As far as I remember, the threading problems were within a process. Multiple processes are probably fine.

  • Anonymous
    April 14, 2009
    The comment has been removed

  • Anonymous
    April 14, 2009
    The comment has been removed

  • Anonymous
    April 15, 2009
    The comment has been removed

  • Anonymous
    April 15, 2009
    If you're creating that many profiles, you're doing it wrong. You should look at CreateStoreEntryID (which is thread safe - all it does is bit twiddling). I'm not dismissing your concerns, but concocting scenarios won't make these interfaces thread safe. Any calls into them need to be serialized.

  • Anonymous
    June 22, 2016
    The comment has been removed