Updated MAPI Download Fixed Crashes


We got a number of reports of crashes using the MAPI download we shipped in December (6.5.8147, also republished with minimal changes in January as 6.5.8153). I’m pleased to announce that we’ve updated the MAPI download with a fix for these crashes.

Details about the MAPI Download:

  • The version which addresses the widespread crashes is 6.5.8165, dated 4/5/2010.
  • If you already have a version of the MAPI Download installed, you must unininstall it before installing the new version. The installer does not upgrade, nor does it warn you if you try to install it without uninstalling the previous version.

The new MAPI Download fixes a few problems the December/January builds had:

  • A worker thread continues running after emsmdb32 has unloaded, crashing when it is next signaled. (http://support.microsoft.com/kb/980291)
  • CDO can free the same memory twice while accepting a meeting update.

An item not fixed by this release:

  • If you have a debugger attached while your application is releasing MAPI, there may be a first chance Access Violation thrown during the unload of emsmdb32.dll. This AV is benign and can be ignored. It will be handled before the call stack returns to your code. The AV should be addressed in a future version of the download.

If I identify other issues fixed by the updated MAPI download, I’ll add them in here.

Enjoy!

Comments (15)

  1. Chris Concern says:

    Has there been any documention i.e release notes or KB articles to that outline the changes made in code or specifics on the issues?

  2. Stephen Griffin says:

    Chris – this post *is* the documentation for the release.

  3. Len says:

    I downloaded 6.5.8165 and notice random MAPI_E_NETWORK_ERROR when calling OpenEntry on the Inbox of the mailboxes and GetContentTable to mailbox on Exchange 2007.  I don't see random crashes anymore.

    Going back to 6.5.8131, I don't see this MAPI_E_NETWORK_ERROR.

    Notice this when we have 50+ mailboxes opened.

    Are there known issues with this latest release?

  4. Stephen Griffin says:

    Other than the known first chance AV on shutdown, there are no known issues with this release.

  5. Nigel says:

    We're seeing a change in behaviour to do with named property mappings in this version of MAPI (6.5.8162.0) compared with the version were using previously (6.5.8039.0). I found this whilst tracking down an issue our testers found in our application.

    I've done a simple application that logs onto exchange, opens a mail box and gets the property tag for a named property we've defined previously (GUID/Name combination). It then opens another mailbox from a different storage group and gets the tag for the same property.   Both mailboxes are hosted on an exchange 2k3 box.

    With 6.5.8039.0 the property tags returned are different for each mailbox.  With 6.5.8162 if the mapi stores are both open the property tags are the same.  If I release the first mailbox then the propery tag is different for 2nd mailbox (and in this case they both match what 6.5.8039.0 gave)

    We think this is what is causing a few issues for us in testing our own application as we open up to 3 mailboxes concurrently and use the named properties both in restrictions for getting the messages and setting the values for future use.

    Is this a regression or a fix in the new version, or is it something more complex going on?

  6. Stephen Griffin says:

    We've not seen this here. You should open a case on this.

  7. Nigel says:

    Ok – I will do that.  There's a definate issue here as my test app now sets a value on a named prop on a message in each mailbox but only one of them can later be retrieved.  

    However this is only happening for 2 mailboxes on an exchange 2k3 server.  If I try 2 mailboxes on 2k7 then it's ok.

    But as you say, I should stop waffling here and go open a case.  Thanks 🙂

  8. Nigel says:

    I opened a case and the support person confirmed it.  This version of MAPI has an issue working with Exchange 2003 and named properties – however as both MAPI and Exchange 2003 are in extended support it sounds like it's unlikely to get fixed.

  9. Mike says:

    Hi Steve

    Are you aware of any issues with this MAPI version regarding public folder access ?

    In my app OpenMessageStore returns -2147221219. MDBVU32 and MFCMAPI display the credentials dialog, but entering credentials of a user with Public Folder Access rigths does not work..

  10. Alan W. says:

    I am seeing an issue with 6.5.8165.0 that was not present in 6.5.8147.0

    I create a profile for a user with full access rights to all mailboxes and then establish a MAPI session.

    Using this session I open a mailbox using CreateStoreEntryID and OpenMsgStore and to close I call StoreLogoff then release the store MDB pointer.

    In 6.5.8165.0 if I iterate over a large series of mailboxes, opening and closing each one then, after 40 -50 iterations, I will receive an 0x8004011d error and the Exchange Event Log will contain the error: Mapi session "f122e4c2-a693-46ed-a585-1a85989f5593" exceeded the maximum of 32 objects of type "session". If I insert a one second delay after closing the mailbox then the problem is eliminated.

  11. Stephen Griffin says:

    Alan – This is the first we've heard of this. Normally, I would say you're leaking objects, but the delay makes it clear we're just taking a little while to close the session down. Most likely, your rapid subsequent logons are grabbing critical sections and preventing the logoff from completing in a timely manner.

    You can open a case on this, but given the easy workaround, it's not likely we'll do anything to address this.

  12. Alan W. says:

    Stephen – Thanks for the quick reply.

    As this is a real time application I'm reluctant to introduce a one second delay.

    Digging deeper I discovered that if I open a mailbox before iterating then all is well. So I assume that each time the last mailbox is closed on a session that the DLL is closing the session as well!! Thus by keeping at least one mailbox open on the session I can mask the problem. – I just hope the administrator doesn't delete my "keep alive" mailbox – lol.

  13. Lev says:

    Hi Steve. Do you have information regarding MAPI download released on Oct. 25?

    Thanks.

  14. Vit S. says:

    Steve – do you know some information regarding to crashes (AV) in MSPST32.dll 6.5.8244.0 from Exchange 2010 SP1? I sometimes have got crashes during MapiUnitialize. They looks like an access to freed memory.

    Thanks.

    617D8E95  mov         eax,dword ptr [edi+40h]  

    EAX = 00000000 EBX = F0F0F0F0 ECX = 00000001 EDX = 056401B8 ESI = 081E07F0 EDI = F0F0F0F0 EIP = 617D8E95 ESP = 0018FAFC EBP = 0018FB14 EFL = 00000000

    > MSPST32.DLL!617d8e95()

    [Frames below may be incorrect and/or missing, no symbols loaded for MSPST32.DLL]

    MSPST32.DLL!617f8a0a()

    EXMAPI32.DLL!61e514cc()

    EXMAPI32.DLL!61e484c4()

    mapi32.dll!_MAPIUninitialize@0()  + 0x4d bytes

  15. Stephen Griffin says:

    We're trying to destroy a message store object there, which involves walking a chain of open objects and destroying them. I'd suggest this is most likely a reference tracking problem in your code. Either you've release an object too many times, destroying it before other object which had a reference to it could call release, or you've failed to release it enough, extended the object's lifespan beyond what it normally should have been.