Microsoft KB Archive/222837

= You cannot call ActiveX Scripting engine methods from non-base threads in Visual C++ =

Article ID: 222837

Article Last Modified on 1/5/2006

-

APPLIES TO


 * Microsoft Visual C++ 6.0 Enterprise Edition
 * Microsoft Visual C++ 6.0 Professional Edition
 * Microsoft Visual C++ 6.0 Standard Edition
 * Microsoft Visual C++ 2005 Express Edition
 * Microsoft Visual C++ .NET 2003 Standard Edition
 * Microsoft Visual C++ .NET 2002 Standard Edition

-



This article was previously published under Q222837



Note Microsoft Visual C++ .NET 2002 and Microsoft Visual C++ .NET 2003 support both the managed code model that is provided by the Microsoft .NET Framework and the unmanaged native Microsoft Windows code model. The information in this article applies only to unmanaged Visual C++ code. Microsoft Visual C++ 2005 supports both the managed code model that is provided by the Microsoft .NET Framework and the unmanaged native Microsoft Windows code model.



SYMPTOMS
When an ActiveX Scripting host calls a method on an ActiveX Scripting engine, such as Visual Basic Script or Java Script, from a thread other than the one that created the engine, the call might fail with HRESULT E_FAIL or E_UNEXPECTED.



CAUSE
After an ActiveX Scripting engine has received a reference to its host by calling the IActiveScript::SetScriptSite method, the scripting engine can no longer accept calls from non-base threads. This happens because the scripting engine checks the thread that makes each call and rejects any calls from non-base threads. NOTE: The base thread is the one that called IActiveScript::SetScriptSite.



RESOLUTION
After the IActiveScript::SetScriptSite method has been called, you cannot call scripting engine methods on non-base thread, however, there are two notable exceptions to this rule:


 * You can call the IActiveScript::InterruptScriptThread method from any thread, thus giving the host a chance to stop a script that has become stuck.
 * You can call the IActiveScript::Clone method from any thread, thus giving the host the ability to set up a standard scripting engine and then replicate it for multiple job runs.



STATUS
This behavior is by design.

ActiveX Scripting engines were designed to behave this way because a truly free-threaded scripting engine would require that every single method in the engine be shielded with critical sections, mutexes, or some other synchronization method. This would result in massive overhead and slow downs.

