PRB: Problem with Abrupt Termination of WBEM Providers

ID: Q196649

The information in this article applies to:

Web-Based Enterprise Management (WBEM), version 1.0

SYMPTOMS

When WBEM service is stopped by the user (either explicitly or during system shutdown), any providers (instance, class, event, and so on) that are still loaded at that time will not be released. Also, an in-process provider's DllCanUnloadNow entry point will not be called. Moreover, if an in-process provider is in the middle of a method call at the time of the shutdown, the executing thread can be terminated in the middle of the call. If WBEM shuts down while a provider is loaded, some of the routines that normally handle cleanup (the object's destructor and DllCanUnloadNow) are not called. The only routine guaranteed to be called (except in exceptional circumstances) is the DLL entry point ("DllMain"). This makes provider cleanup more difficult.

Because it is possible that WBEM will shut down in the middle of a call, providers must make sure that they do not leave their data sources in an inconsistent state. For read-only providers this is generally not a problem. Providers with write capabilities may want to implement some sort of transactioning to allow a safe rollback after an abrupt termination.

When the WBEM service exits, the operating system will automatically release all memory allocated to an in-process provider, and will close most resources held by the provider, including file handles, window handles, mutexes, and so on. This includes both in-process and out-of-process providers, COM-based or otherwise. The provider does not need to take any specific action to make this happen.

Certain types of resources are not automatically released by the operating system; an example would be a socket, or a database connection. Such resources may need to be manually cleaned up by the provider. One place to perform this sort of cleanup is DllMain--the DLL entry point function that is called (once) when the DLL is being unloaded.

Cleanup code can be added directly into DllMain, executing it in response to DLL_PROCESS_DETACH. This can be somewhat difficult to arrange, especially in programming environments like MFC or ATL. For additional information, please see the following article in the Microsoft Knowledge Base:

Q148791 How to Provide Your Own DllMain in an MFC Regular DLL

An alternative approach is to put the cleanup code in the destructor of a global class. Global objects are not allocated on the heap, and are automatically destroyed during DLL unload. For example:


   class CMyCleanup
   {
      ~CMyCleanup()
      {
         CloseHandle(m_hOpenFile);
         CloseDatabaseConnection(g_hDatabase);
      }
   } g_Cleanup;

There are many restrictions as to what can be done in the cleanup code with either approach. Neither threads, nor any DLLs that are not implicitly linked, may be accessed in any way, and COM calls cannot be made under any circumstances. See "Win32 Q & A" in Microsoft Systems Journal March 1996 Number 3 and September 1996 Number 9 for more information.

Note that out-of-process providers do not experience any of these problems, because they are not terminated when WBEM service shuts down. Providers for whom cleanup and termination robustness issues are more important than performance may want to consider making themselves out-of-process.

STATUS

This problem is scheduled to be corrected in a future release.

REFERENCES

For additional information, please see the following article in the Microsoft Knowledge Base:

Q148791 How to Provide Your Own DllMain in an MFC Regular DLL

Additional query words: kbDSupport

Keywords : kbweb kbDLL kbMFC kbWBEM100
Version :
Platform : winnt
Issue type : kbprb