How to Debug WEP(), _WEP(), and ExitInstance() in 16-bit DLLs

ID: q148734

The information in this article applies to:

Microsoft Visual C++ for Windows, 16-bit edition, versions 1.0, 1.5, 1.51, 1.52

SUMMARY

The Visual C++ Workbench debugger does not support debugging the Windows Exit Procedure (WEP) or functions called from WEP for implicitly loaded DLLs. CodeView for Windows does support debugging WEPs but only if the calling application is not the application being debugged by CodeView for Windows.

Breakpoints set through the debugger or DebugBreak() will not be hit. MFC TRACE() statements and OutputDebugString() messages will not show up in the debug window. However, DBWIN can be used to see these debug messages. DBWIN can be started from the Program Manager by opening the DebugWin icon or by running Dbwin.exe from the Msvc\Bin directory.

NOTE: CodeView requires Windows 3.1 and is not compatible with Windows NT or Windows 95.

MORE INFORMATION

Both the Workbench debugger and CodeView for Windows stop debugging when the main application being debugged exits. This occurs before the implicitly linked DLLs are actually unloaded from memory and their Windows Exit Procedures (WEPs) are called.

By default, the Windows Exit Procedure (WEP) is implemented by the C Run-Time (CRT). The CRT version of WEP calls _WEP(), the user-defined Windows Exit Procedure. In MFC _USRDLLs, _WEP() in turn calls ExitInstance(). Also, all destructors for static C++ objects are called from the default CRT WEP. This debugger limitation applies to all of these functions.

Step-by-Step Example for Debugging Procedure

Because CodeView for Windows supports multi-process debugging, it is possible to work around this problem by following these steps:

Start CodeView for Windows, and debug some unrelated 16-bit application that does not load the DLL you want to debug. Solitaire (Sol.exe), which ships with Windows, is an example of a good application to use.

Start debugging by pressing the F5 key. If the application you chose to debug wasn't built as "debug," ignore the message about no CodeView information.

Start the application that loads the DLL by using File Manager. CodeView will automatically load the debug information for the DLL when the DLL is loaded.

Break into CodeView for Windows by pressing CTRL+ALT+SYSREQ. At this point, you can set breakpoints in the DLL. Note, if you need to debug other parts of the DLL, you could have also set breakpoints by pre-loading the debugging info before step 2.

At this point, you can debug the WEP as any other function. You will need to exit the program that's being debugged (Sol.exe) to exit CodeView. You will also need to exit CodeView if you need to re-start your application.

Implicitly loaded DLLs are DLLs that are loaded automatically by Windows by linking with an import library or by using the IMPORTS module definition file statement.

In DLLs that are explicitly linked, loaded, and freed through LoadLibrary() and FreeLibrary(), there are no problems debugging the WEP both the Workbench debugger and CodeView for Windows.

REFERENCES

For more information on why breakpoints fail, please see the following article in the Microsoft Knowledge Base:

Q121556 PRB: Breakpoints Won't Work - 11 Reasons Why

This article covers, among other things, why breakpoints may not work in MFC source code files. See the "Breakpoints Fail When Multiple Source Files Have the Same Name" section for more information.

Additional query words: 1.00 1.50 kbinf CVW

Keywords : kb16bitonly kbCodeView kbDebug kbDLL kbide kbMFC kbVC
Version : 1.00 1.50 1.51 1.52
Platform : WINDOWS
Issue type :