The information in this article applies to:
SYMPTOMSAn ATL Component Object Model (COM) dynamic-link library (DLL) that registers and creates a window and runs on the Windows NT or Windows 2000 operating system, can cause an access violation. CAUSE
ATL does not unregister the window classes that it registers. RESOLUTIONUnregister all of the window classes of the windows that you are creating inside of your ActiveX control. Use the code shown in the "Sample Code" section to unregister the window classes in the destructor of your class. Resolution for CContainedWindow UseIf you have a CContainedWindow object in your class, the m_lpszClassName member of the CContainedWindow class stores the class name that was used to register the class. The sample code uses the same logic that is used by ATL (in Atlwin.cpp, CContainedWindow::RegisterWndSuperclass) to construct the window class name, and uses that name to unregister the class:Sample Code
Replace m_MyContainedWnd with your CContainedWindow object name.
Resolution for CWindowImpl UseIf you have an ActiveX control or use one of the DECLARE_* macros, use code similar to the following:
Replace CMyClass with your class name.If you have multiple contained windows or have a contained window in a control, use both of these resolutions, according to how you have used the contained windows. STATUSMicrosoft has confirmed this to be a problem in the Microsoft products listed at the beginning of this article. MORE INFORMATIONFor additional information, click the article number below to view the article in the Microsoft Knowledge Base: Q167526 Steps to Reproduce the ProblemThis problem is difficult to reproduce. This behavior only occurs under the following conditions (for example):
The HINSTANCE value of a DLL is equal to the base address into which it was loaded. When DLL A registered the Button class, it assigned a WndProc address for the class in the address range of where it was loaded. DLL B also registered another class with the same name, but with a different WndProc location in its address space. Please note these window classes are local to the module that registered them. Thus, Button was registered from two different DLLs, even though the two DLLs were loaded in the same process. The HINSTANCE value determines whether a given DLL has already registered a particular window class. When you create a window by using ATL, ATL firsts attempts to find whether a window class was registered for the given window by using the ::GetClassInfoEx function. If the class is not registered, then ATL will register the class and create the window. In the scenario in the "Steps to Reproduce the Problem" section, DLL A and DLL B both register the Button class with different WndProc addresses. Assuming DLL B loaded first the second time around, this time at the base address of DLL A, the ::GetClassInfoEx function returns the WndProc address that was registered by DLL A for the Button class. The address is invalid, and the first call to it causes an access violation. REFERENCESFor more information on the GetClassInfoEx function, please see the following MSDN reference: http://msdn.microsoft.com/library/psdk/winui/winclass_2jp4.htmFor more information on the RegisterClassEx function, please see the following MSDN reference: http://msdn.microsoft.com/library/psdk/winui/winclass_0wc8.htmFor a Window Classes Overview, please see the following MSDN reference: http://msdn.microsoft.com/library/psdk/winui/winclass_1ooj.htmFor additional information, click the article number below to view the article in the Microsoft Knowledge Base: Q167526 FIX: ATL Control May Cause an Access Violation Additional query words: CreateWindowEx Random Crash SuperClass Multiple
Keywords : kbActiveX kbATL200bug kbATL210bug kbATLWC kbCOMt kbCtrlCreate kbInprocSvr kbNTOS400 kbWinOS2000 kbVC500bug kbVC600bug kbATL300bug kbGrpMFCATL |
Last Reviewed: January 28, 2000 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |