ID: Q195423
The information in this article applies to:
An improperly written WBEM provider causes CIMOM (WinMgmt) to crash or lockup.
Make sure your implementation of provider methods does not result in CIMOM and your provider calling each other recursively.
1. The provider implements a method that makes a call to CIMOM. For
example, suppose you have a class provider with the following
implementation of GetObjectAsync:
HRESULT STDMETHODCALLTYPE MyClassProvider::GetObjectAsync(
/* [in] */ BSTR strObjectPath,
/* [in] */ long lFlags,
/* [in] */ IWbemContext __RPC_FAR *pCtx,
/* [in] */ IWbemObjectSink __RPC_FAR *pResponseHandler)
{
IWbemClassObject *pNewClass = 0;
// This GetObject call results in unterminated recursion.
m_pNamespace->GetObject(strObjectPath, 0, pCtx, &pNewClass, NULL);
// The proper GetObject call should be:
// m_pNamespace->GetObject(NULL, 0, NULL, &pNewClass, NULL);
// Provide the class definition to CIMOM.
.
.
.
}
When this provider is registered with CIMOM, CIMOM will call this
method.
2. The call to CIMOM results in a call to that same method in the provider.
In this example, the GetObject call calls back to CIMOM, which calls
back to this same method, and so forth.
RESULT: An unterminated recursion results, which causes CIMOM to lockup or
crash.
If the provider is an in-proc provider, this recursion continues until CIMOM crashes with a stack fault.
If the provider is an out-of-proc provider, a new thread from the thread pool is used for each request. CIMOM then locks up when the thread pool is exhausted. In this state, CIMOM will not even be able to shut down properly since there is no thread available to perform the shutdown. You can unlock CIMOM by terminating the provider.
WBEM SDK
Additional query words:
Keywords : kbWBEM kbWBEM100
Issue type : kbprb
Last Reviewed: November 7, 1998