CDOEXM CreateMailbox is leaking memory

Patrick Creehan — Mon, 21 Jan 2008 18:07:00 GMT

I had a case recently where the customer had built an application to help manage their Active Directory environment. Part of this application used CDOEXM to create new mailboxes for their new user accounts. This is a common use of CDOEXM - nothing wrong so far. What this particular application was doing though was that when it had new work to do, it would spawn a new thread. On that new thread, they would CoInitialize, do their CDOEXM work, then CoUninitialize. The customer was reporting that the process leaked memory. Sure enough, commenting out the call to CreateMailbox prevented the leak.

After debugging, I discovered that some of the functions in the CreateMailbox code path use static variables. Each time CDOEXM is loaded and the execution hits those static variables for the first time, they'll be created in the static heap. Since his application spawned a new thread that did this for each user, the memory would increase by this amount each time. So the leak wasn't really a leak as much as it was just the way static variables work and the way his application was structured simply used an increasing amount of memory.

By moving his loop inside the CoInitialize/CoUninitialize block, the memory usage remained static.

So it seems that CDOEXM is not going to work well in an architecture like this. Here are some ideas for how to architect your solution to not run into this problem:

Spawn a new process to do your CDOEXM work (which will terminate when finished).
Create a low (finite) number of background worker threads you can persist throughout the lifetime of your process that you can queue CDOEXM work to. This will allow you to call CoInitialize/CoUninitialize a controlled number of times.
Put the CDOEXM code in a COM+ component and call it from your application. This way, your CDOEXM code just gets loaded in dllhost and you don't have to worry about it. Here's an article Matt wrote about how to do this in managed code.

Ooh, SNP

Patrick Creehan — Tue, 16 Oct 2007 23:46:00 GMT

We've recently been seeing an elevated number of cases where networking issues are adversely affecting performance and causing other problems with messaging technologies. The common thread in many of them is that the problem only started to occur after Windows Server 2003 SP2 was installed. I recently learned that we shipped a new feature in SP2 and turned it on by default. This new feature is called Scalable Networking Pack, or SNP. It was actually originally shipped as a download for SP1, but was included in SP2 by default.

The Exchange team has posted an article on how SNP affects Exchange and also gives a good list of links and troubleshooting steps.

SNP was built to increase performance on the networking stack, and does for newer network adapters that support it. However, for older network adapters, it can cause significant delays which cause timeout problems and connection problems leading to various problems.

The basic troubleshooting steps at this point are

Read the Exchange team's post linked above and pages they reference so you understand the issue
Install the hotfix at http://support.microsoft.com/kb/936594
Upgrade your network adapter drivers to the most recent version
Disable the SNP features by setting the following registry keys:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]

EnableTCPChimney=dword:00000000

EnableTCPA=dword:00000000

EnableRSS=dword:00000000

UPDATE:

I've just had another case where SNP was the culprit. The customer had clustered Exchange 2003 boxes with recently applied SP2. They were using backup software which was using CDOEXM to get information about the environment. These calls were failing with 0x8000FFFF (E_UNEXPECTED) but after debugging we saw that RPC was getting RPC_S_SERVER_UNAVAILABLE (1722 0x6ba) errors. This prompted me to ask about SNP. Disabling SNP via the steps above resolved the issue.

UPDATE (1-8-07):

Yet again, another customer with clustered Exchange 2007 boxes. They had a MAPI application which was unable to OpenMsgStore on mailboxes that had migrated from Exchange 2003 (MAPI_E_FAILONEPROVIDER). Debugging the process I could see RPC_S_SERVER_UNAVAILABLE errors. Sure enough, they had SP2 installed. Disabling SNP resolved the issue. The reason nonmigrated mailboxes worked was that MAPI was just guessing the ServerDN since resolving against the DS didn't work. If the mailbox had never been migrated, this guess ended up being correct; for migrated mailboxes, it was wrong and the failure bubbled up.

Wiz/dumb : CDOEXM

CDOEXM CreateMailbox is leaking memory

Ooh, SNP