A memory leak caused by msado15.dll

 

Customer has COM+ application running on Windows Vista SP2. Found memory keeps increasing. After enabled Memory Leak tracking on application process by DebuDiag, we canptured memory dump successfully. From the memory dump, using DebugDiag Analsyis:

 

1. Found the leakage pattern points to the functions:

 

msado15.dll is responsible for 146.24 MBytes worth of outstanding allocations. The following are the top 2 memory consuming functions:

 

msado15!CSysString::operator=+2e: 146.23 MBytes worth of outstanding allocations.

msado15!CSysString::operator=+52: 1.92 KBytes worth of outstanding allocations.

 

2. Look further in Busy Heap Entry in the huge heap, we can see many connection strings involved:

 

0:000> !heap -a b0000

Index Address Name Debugging options enabled

  1: 000b0000

....

      07f3a538: 001c0 . 10000 [101] - busy (fff8) Internal

        07f4a538: 10000 . 20000 [101] - busy (1fff8) Internal

        07f6a538: 20000 . 20000 [101] - busy (1fff8) Internal

        07f8a538: 20000 . 02000 [101] - busy (1ff8) Internal

        07f8c538: 02000 . 00800 [101] - busy (7f8) Internal

......

 

0:000> du

07f4a55c "Provider=SQLOLEDB.1;Persist Secu"

07f4a59c "rity Info=False;User ID=xxxx;In"

07f4a5dc "itial Catalog=xxxxxx;Data Source"

07f4a61c "=xxxxx;Use Procedure for Prepa"

07f4a65c "re=1;Auto Translate=True;Packet "

07f4a69c "Size=4096;Workstation ID=xxxxx"

07f4a6dc "-xxxxxx;Use Encryption for Data"

07f4a71c "=False;Tag with column collation"

07f4a75c " when possible=False"

...

0:000>

07f4b864 "Provider=SQLOLEDB.1;Persist Secu"

07f4b8a4 "rity Info=False;User ID=xxxxx;In"

07f4b8e4 "itial Catalog=xxxxxx;Data Source"

07f4b924 "=xxxxx;Use Procedure for Prepa"

07f4b964 "re=1;Auto Translate=True;Packet "

07f4b9a4 "Size=4096;Workstation ID=xxxxx"

07f4b9e4 "-xxxxxxx;Use Encryption for Data"

07f4ba24 "=False;Tag with column collation"

07f4ba64 " when possible=False"

 

From the two points, the known issue was hit:

 

978042 FIX: A memory leak may occur when you use the Microsoft ActiveX Data Objects Library in Windows Vista, in Windows 7, in Windows Server 2008, or in Windows Server 2008 R2

https://support.microsoft.com/kb/978042/EN-US

 

As a summary, to detect this known issue , we follow below check list:

 

1. The current msado15.dll version is lower than below item on certain platforms:

 

For all supported x86 version of Windows Vista and Windows Server 2008

Msado15.dll 6.0.6000.21172

 

For all supported x86 version of Windows Vista SP1 and Windows Server 2008

Msado15.dll 6.0.6001.22574

 

For all supported x86 version of Windows Vista SP2 and Windows 2008 SP2

Msado15.dll 6.0.6002.22280

 

For all supported x64 version of Windows Vista and Windows Server 2008

Msado15.dll 6.0.6000.21172

 

For all supported x64 version of Windows Vista SP1 and Windows Server 2008

Msado15.dll 6.0.6001.22574

 

For all supported x64 version of Windows Vista SP2 and Windows 2008 SP2

Msado15.dll 6.0.6002.22280

 

For all supported Itanium-based version of Windows Server 2008 SP1

Msado15.dll 6.0.6001.22574

 

For all supported Itanium-based version of Windows Server 2008 SP2

Msado15.dll 6.0.6002.22280

 

For all supported x86 version of Windows 7

Msado15.dll 6.1.7600.20589

 

For all supported x64 version of Windows 7 and of Windows Server 2008 R2

Msado15.dll 6.1.7600.20589

 

For all supported Itanium-based version of Windows Server 2008 R2

Msado15.dll 6.1.7600.20589

 

-And-

 

2. In the ADO connection string, "Persist Security Info=False" instead of True

 

If the point 2 cannot be retrieved from memory dump easily, can use this point 3 to confirm with point 1 together.

 

3. The leakage function is reported as msado15 casued in DebugDiag:

 

msado15.dll is responsible for 146.24 MBytes worth of outstanding allocations. The following are the top 2 memory consuming functions:

 

msado15!CSysString::operator=+2e: 146.23 MBytes worth of outstanding allocations.

msado15!CSysString::operator=+52: 1.92 KBytes worth of outstanding allocations.

 

Regards,

Freist Li from APGC DSI Team