This article was previously published under Q312575
This article has been archived. It is offered "as is" and will no longer be updated.
An application or service with large numbers (more than 500) of concurrently open ActiveX Data Objects (ADO) recordsets that are opened and closed frequently may experience a virtual memory leak that leads to memory fragmentation and out-of-memory errors.
This problem can occur in any version of Microsoft Data Access Components (MDAC) between 2.5 RTM (2.50.4403.12) and 2.6 SP1 (2.61.7326.6). This problem does not occur in MDAC 2.7.
This problem is not provider-specific; it can occur with the SQL Server native provider (Sqloledb.dll), the Oracle native provider (Msdaora.dll), the ODBC provider (Msdasql.dll), the client cursor engine, and any component that uses the shared memory code.
When recordsets are released, the MDAC memory management routines save the memory allocated for them in a "look-aside" list rather than actually freeing the memory. This is done to avoid the overhead incurred by completely freeing and reallocating memory.
By default, the shared memory management code used by MDAC 2.5 (Msdatl2.dll) and MDAC 2.6 (Msdatl3.dll) will save up to 500 of these allocations; anything over that amount is freed through calls to the VirtualFree function.
A coding error in the memory management code makes an incorrect call to VirtualFree, so that the memory is not actually released. The return code from VirtualFree is not checked, and the application receives no indication that the memory was leaked.
To resolve this problem, obtain the latest service pack for Microsoft MDAC 2.5. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
293312INFO: How to Obtain the Latest MDAC 2.5 Service Pack
The English version of this fix should have the following file attributes or later:
MDAC 2.5 SP2
Date Version Size File name ------------------------------------------------- 25-Oct-2001 2.52.8025.0 78,096 Msdatl2.dll 25-Oct-2001 2.52.8025.0 53,520 Msdatt.dll 25-Oct-2001 2.52.8025.0 303,376 Msdasql.dll 25-Oct-2001 2.52.8025.0 16,384 Msdasqlr.dll 15-Nov-2001 Q312575_MDAC25_SP2_x86_en.exe
For MDAC 2.5 only: To resolve this problem, obtain the latest service pack for Windows 2000. For additional information, click the following article number to view the article in theMicrosoft Knowledge Base:
260910 How to Obtain the Latest Windows 2000 Service Pack
MDAC 2.6 SP1
Date Version Size File name ------------------------------------------------- 25-Oct-2001 2.61.8025.0 94,480 Msdatl3.dll 25-Oct-2001 2.61.8025.0 24,848 Msdatt.dll 25-Oct-2001 2.61.8025.0 307,472 Msdasql.dll 25-Oct-2001 2.61.8025.0 16,384 Msdasqlr.dll 15-Nov-2001 Q312575_MDAC26_SP1_x86_en.exe
To work around this problem, you can design your application or service so that less than 500 recordsets are open concurrently.
You can alleviate the problem by adjusting the following settings in the registry:
Note that these registry entries do not exist by default; you need to add then manually. Both entries are DWORD values.
The default value for MaxReservedBlocks is 500. If you increase this value, more blocks will be saved in the memory manager's look-aside list (and will therefore incur more memory usage in the application) but the blocks will be reused. If you lower this value, the rate at which memory is leaked will increase.
The default value for ReservedMemorySize is 1 MB. You can lower this value to limit the size of the virtual memory allocations; however, this may decrease performance if more memory is required than what is available in the memory blocks.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.
This problem was first corrected in Microsoft MDAC 2.5 Service Pack 3. This problem was first corrected in Windows 2000 Service Pack 3.
In MDAC 2.5, the leaked memory allocations will consist entirely of Reserved memory and will have no committed pages; for example: