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. (https://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
Anonymous
May 02, 2010
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?Anonymous
May 02, 2010
Chris - this post is the documentation for the release.Anonymous
May 28, 2010
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?Anonymous
May 28, 2010
Other than the known first chance AV on shutdown, there are no known issues with this release.Anonymous
June 08, 2010
The comment has been removedAnonymous
June 08, 2010
We've not seen this here. You should open a case on this.Anonymous
June 08, 2010
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 :)Anonymous
June 23, 2010
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.Anonymous
August 19, 2010
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..Anonymous
October 04, 2010
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.Anonymous
October 04, 2010
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.Anonymous
October 04, 2010
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.Anonymous
October 26, 2010
Hi Steve. Do you have information regarding MAPI download released on Oct. 25? Thanks.Anonymous
November 11, 2011
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 bytesAnonymous
November 15, 2011
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.