Article ID: 272373 - View products that this article applies to.
This article was previously published under Q272373
This article has been archived. It is offered "as is" and will no longer be updated.
When running multithreaded ActiveX Data Objects (ADO) code under high stress on a multiprocessor computer, an access violation (AV) may occur when closing an ADO Recordset. Examination of the call stack at the time of the AV (with the appropriate debugging symbols installed) reveals that the last ADO call on the stack is a call to the ADO internal function msado15!CCollectionArray__Delete.
This problem is fixed in the latest service packs for Microsoft Windows 2000, MDAC 2.5, and MDAC 2.6, and in MDAC version 2.7.
HotfixThe English version of this fix have the following file attributes or later:
Date Version Size File name Platform ----------------------------------------------------------- 09/15/2000 2.51.5715.0 487,696 Msado15.dll x86
Avoid closing an ADO Recordset and its parent ADO Connection object at exactly the same time on 2 different threads, or apply this hotfix.
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 Data Access Components (MDAC) 2.5 Service Pack 2, MDAC 2.6 Service Pack 1, MDAC 2.7, and Microsoft Windows 2000 Service Pack 2.
To reproduce the problem, an ADO Recordset and its parent ADO Connection must be closed or released on 2 different threads at exactly the same time. Note that this issue has only been successfully reproduced on a multiprocessor machine.
The initial problem was discovered by using the Windows Foundation Classes (WFC) ADO Java classes in a COM+ application under heavy stress with ADO set to free-threaded mode. The Microsoft virtual machine (Microsoft VM) defers the release of COM objects until the garbage collector is activated. Also, the garbage collector performs the release of the COM object on a background thread. If you close a WFC ADO Connection, this places the ADO Connection COM interface pointer into a list of pointers for future cleanup by the garbage collector. If the main application code subsequently closes an ADO Recordset at exactly the same time that the garbage collector background thread releases its parent ADO Connection interface pointer, the AV can occur.
Article ID: 272373 - Last Review: January 11, 2015 - Revision: 8.1