Microsoft KB Archive/312575

= FIX: Virtual Memory Leak with Large Number of Concurrently Open Recordsets =

Article ID: 312575

Article Last Modified on 4/7/2006

-

APPLIES TO


 * Microsoft Data Access Components 2.5
 * Microsoft Data Access Components 2.5 Service Pack 1
 * Microsoft Data Access Components 2.5 Service Pack 2
 * Microsoft Data Access Components 2.6
 * Microsoft Data Access Components 2.6 Service Pack 1

-



This article was previously published under Q312575



SYMPTOMS
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.



CAUSE
When recordsets are released, the MDAC memory management routines save the memory allocated for them in a &quot;look-aside&quot; 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.



RESOLUTION
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 the Microsoft 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



WORKAROUND
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:    HKLM\Software\Microsoft\MDAC         MaxReservedBlocks HKLM\Software\Microsoft\MDAC        ReservedMemorySize 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.



STATUS
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.

MDAC 2.5
This problem was first corrected in Microsoft MDAC 2.5 Service Pack 3. This problem was first corrected in Windows 2000 Service Pack 3.



MORE INFORMATION
In MDAC 2.5, the leaked memory allocations will consist entirely of Reserved memory and will have no committed pages; for example: 08230000,     Private,    1048576,     1, -RW-, 08230000, Reserve,   1048576,,       -RW- --, 08330000,     Private,    1048576,     1, -RW-, 08330000, Reserve,   1048576,,       -RW- --, 08430000,     Private,    1048576,     1, -RW-, 08430000, Reserve,   1048576,,       -RW- --, 08530000,     Private,    1048576,     1, -RW-, 08530000, Reserve,   1048576,,       -RW- --, In MDAC 2.6 the leaked memory allocations will contain at least 10 KB (65536 bytes) of committed pages; for example: 1BF60000,     Private,    1048576,     2, -RW-, 1BF60000, Private,     65536,,       -RW- --, 1BF70000, Reserve,    983040,,       -RW- --, 1C060000,     Private,    1048576,     2, -RW-, 1C060000, Private,     65536,,       -RW- --, 1C070000, Reserve,    983040,,       -RW- --, 1C160000,     Private,    1048576,     2, -RW-, 1C160000, Private,     65536,,       -RW- --, 1C170000, Reserve,    983040,,       -RW- --, In either case, monitoring the application or service with Performance Monitor shows an excessive use of virtual bytes.

Additional query words: kbMDAC virtual memory reserved leak maxreservedblocks reservedmemorysize large number recordsets open simultaneously concurrently fragmentation 500 out of

Keywords: kbbug kbfix kbqfe kbwin2000sp3fix kbmdac260fix kbmdac250sp3fix kbhotfixserver KB312575

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.