This article was previously published under Q164166
This article has been archived. It is offered "as is" and will no longer be updated.
When you use a Visual C++ 4.x MFC application spawned from a Windows NT service oras a Windows NT service, an assertion may occur in Wincore.cpp. Specifically, itoccurs on the following line in _AfxActivationWndProc():
The assertion occurs on line 385 with Visual C++ versions 4.2 and 4.2b, online 384 with Visual C++ version 4.1, line 392 with Visual C++ version 5.0, and on line 389 with Visual C++ 6.0.
MFC subclasses all non-MFC created windows to handle specific activationissues. While subclassing a non-MFC created window, the old windowprocedure is stored in the properties of the window. Logging off of an Windows NTsession causes the atoms used to identify the properties to be destroyedand the property cannot be retrieved. This causes the assertion to occur.
MFC was not designed for Windows NT services. As a result, if an MFCapplication is spawned from a Windows NT service, minimized, and then auser logs-off, then the assertion will occur.
Also keep in mind that there are other problems to consider when spawningan MFC application from a service or as a service. The OnEndSession()message handler for the main frame window closes out the CDocument object.So the WM_ENDSESSION message must be handled to prevent this fromhappening.
You can do one of the following things:
Unsubclass all of the non-MFC windows at some time before logoff or during logoff such as in the WM_ENDSESSION handler.
Modify the MFC code and rebuild the MFC libraries. In this case, you can modify the MFC code to prevent it from subclassing any non-MFC windows or modify the code so that you can store the old window procedure in a list rather than in properties for the window. As each window is destroyed (WM_NCDESTROY is received), look up the window handle in your list and unsubclass it like MFC does in the _AfxActivationWndProc() function.
Separate the GUI part of the application from the service part. In other words, have a GUI client startup every time the user logs on. Then, have the GUI client talk to the service through some form of interprocess communication, such as named pipes or sockets. The service should maintain the data and the GUI starts up each time when you log on.
MFC subclasses non-MFC windows to generally handle obscure windowactivation issues. For example, it ensures proper activation of toplevelwindows when doing in-place OLE activation. It also ensures that the lastactive popup is activated when a user clicks on a disabled window that ispart of the application. Normally, if you have a main window that owns amodal dialog box and some other popup window like a floating toolbar, andyou switch activation to another application, and click on the toolbar thatwas disabled by the modal dialog box, Windows beeps and does not activatethe application. MFC ensures that the modal dialog box is brought to thetop when you click on the toolbar. Note that MFC handles all of theseactivation issues for MFC-created windows and non-MFC created Windows. Theold window procedure is stored as a property associated with the windowonly for non-MFC windows. If you unsubclass the non-MFC windows (as thefirst technique suggests above), you still get these activation featuresfor any windows that were created as MFC CWnd-derived objects.
Unsubclassing the non-MFC Windows
The first technique listed above may be an easy workaround for developerswho have already written an application and don't want to rework theirdesign, rebuild the MFC libraries, or don't need to handle the activationissues MFC handles.
You can unsubclass non-MFC Windows in the WM_ENDSESSION handler of yourmain frame window. The following sample code demonstrates how to enumerateall of the windows for your process and unsubclass them:For Visual C++ 4.x and Visual C++ 5.0: