The latest MAPI download has an interesting fix in it. Prior to this fix, if you used Exchange's MAPI to connect to Exchange 2007 running on Windows Server 2008 you might crash when you release your message store. If Exchange was running on Windows Server 2003, the same code ran fine. At first, I didn't really believe the version of the OS on the server could trigger a crash on the client, but he had dumps and repro steps, so we debugged it to see what was going on.
Nothing was wrong with his code - we were able to build a simple repro that did nothing more than logon, open the message store, open a folder then release everything. We found some tweaks they could make in their code to avoid the crash, but nothing they were doing was wrong - we even found that MFCMAPI could be walked through to the point of crashing.
The dump of the crash showed we were cleaning up a thread that handled notifications. When we ran the code against an Exchange 2007 server running on Windows 2003, this thread didn't get cleaned up. In fact, it never got created! A bit of debugging back showed the point where we diverged. In both, we tried to register for push notifications with Exchange (these are MAPI's typical UDP based notifications). The Windows Server 2003 based machine succeeded in registering the push notification, but the Windows Server 2008 based machine returned MAPI_E_NO_SUPPORT. This sent us down a little used code path in Exchange's implementation of MAPI. It spun up a timer thread and began polling for notifications. When it tried to tear down this thread, released an object that had been created on another thread. This object had initialized COM, so it tried to uninitialize it when it's destroyed. Since the COM was never initialized on the timer thread, we crashed.
The fix, of course, is to ensure that the object that uses COM is created and destroyed on the same thread. That's the fix we put into last months MAPI download - so if you've been getting unusual crashes while shutting down MAPI clients connected to Exchange 2007 servers on Windows 2008, you'll want to grab this update. A KB article documenting the fix is in the works - I'll link it when it's ready. KB 951992 documents the fix.
Now - you may be wondering - what was happening on the server side? This thread in the newsgroups explains it. EnumProtocols is broken in both Windows 2008 and Vista. It's been replaced by WSAEnumProtocols, which is easy enough to drop in, but of course, you'll need to recompile. We've got a fix for Exchange 2007 in the works that replaces it's call of EnumProtocols with a call to WSAEnumProtocols. If you need it now, you can open a support case and ask for an interim update (ask for KB 951251). Else, it's scheduled to be in Update Rollup 4 for Exchange Server 2007 Service Pack 1 (not the next rollup, but the one after that).
I found this site doing a search for ENumProtocols and while my problem has nothing to do with MAPI/Exchange, I am in a similar situation. Is there any plans to fix eNumProtocols function at all under Vista? We don't have the option of replacing eNumProtocols with the newer function and recomple existing code.
We filed a bug on it, but since we were able to use the workaround it was rejected. You might get different results if you open a case on it.
Wouldn't the real solution be to fix the EnumProtocols function, rather than patch existing code to use WSAEnumProtocols?
Can you point me where I go about opening a case with Microsoft? Thx for your help
I don't disagree. Start here: http://support.microsoft.com
Revisiting the EnumProtocols bug (where EnumProtocols always returns –1 and GetLastError returns ERROR_INVALID_DATATYPE