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 new MAPI Download fixes a few problems the December/January builds had:
An item not fixed by this release:
If I identify other issues fixed by the updated MAPI download, I’ll add them in here.
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?
Chris - this post *is* the documentation for the release.
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?
Other than the known first chance AV on shutdown, there are no known issues with this release.
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?
We've not seen this here. You should open a case on this.
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 :)
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.
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..
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.
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.
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.
Hi Steve. Do you have information regarding MAPI download released on Oct. 25?
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.
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
[Frames below may be incorrect and/or missing, no symbols loaded for MSPST32.DLL]
mapi32.dll!_MAPIUninitialize@0() + 0x4d bytes
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.