Article ID: 241896 - View products that this article applies to.
Not sure if this is the right fix? We've added this issue to our memory dump diagnostic
(https://home.diagnostics.support.microsoft.com/SelfHelp?knowledgebaseArticleFilter=2027760)which can confirm.
When using Visual Basic 6.0 ActiveX components in a multi-threaded environment, you should be aware of the following potential problems:
ActiveX DLL hosted in a multi-threaded client
Note Prior to Service Pack 3 for Visual Studio 6.0, it was possible to get an AV during process shutdown with Retain in Memory enabled. This has been fixed in the latest Visual Studio 6.0 service pack:
If an ActiveX DLL or UserControl project contains API declarations, you may experience deadlocks during process/thread shut down or object creation, even if the Unattended Execution check box has been selected in the case of an ActiveX DLL. To workaround this problem, you can use a Type Library instead of Declare in Visual Basic. For additional information on how to use a Type Library, click the article number%2 below to view the article%2 in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/189133/EN-US/ )HOWTO: Make C DLL More Accessible to VB with a Type Library
ActiveX EXE accessed by a multi-threaded client or by multiple single- or multi-threaded clients
Runtime error '7': out of memory and sometimes followed by a disk operation error.
Run-time error '430': Class does not support Automation or does not support expected interface.
Run-time error '424': Object required.
Run-time error '-2147023170 (800706be)': Automation error. The remote procedure call failed.
Run-time error '-2147287010 (8003001e)': Automation error. This is a "A disk error occurred during a read operation." based on ErrLook.
You may see the error messages listed above if you have an ActiveX EXE server with a thread pool greater than one (1), and a multi-threaded client or multiple single- or multi-threaded clients rapidly creating and destroying objects inside the server. To work around this problem, you can create an empty class in the local server and have the client keep a reference to it as shown in the "More Information" section below.
Additional server processes (ThreadTest.EXE) are created even though the Instancing property of Class1 is marked MultiUse.
This behavior is by design.In Visual Studio 6 Service Pack 5, if a project contains any public class that has MTSTransactionMode set to anything other than 0, the Unattended Execution option and the Retain In Memory option are automatically selected.
Steps to reproduce the behavior
A: Creating the server
B: Creating the client and testing
C: Implementing the workaround
Do not use the GlobalMultiUse Instancing property for a class when you intend to use the ActiveX component under MTS or COM+. The interface for the GlobalMultiUse object is cached in a per thread-based table and is not freed until the thread terminates. As a result, if a call comes in with a different context (although on the same thread), it fails with RPC_E_WRONG_THREAD. To use components in MTS and COM+, you should design your classes in such a way that the objects are stateless.
Article ID: 241896 - Last Review: October 9, 2014 - Revision: 7.0