Microsoft KB Archive/97908

{|
 * width="100%"|

-

The information in this article applies to:


 * Microsoft Win32 Software Development Kit (SDK), versions 3.1, 3.5, 3.51, 4.0

-

SUMMARY
This article describes the process of debugging dynamic-link libraries (DLLs) under WinDbg. As a further example, debugging File Manager extensions under Windows NT is discussed in the &quot;More Information&quot; section in this article.

MORE INFORMATION
The application and the DLL must be built with certain compiler and linker switches so that debugging information is included. These switches can be found in the $(cdebug) and $(ldebug) macros, respectively, which are defined in NTWIN32.MAK.

NOTE: It is important to disable optimization with -Od or locals will not be available in the locals window and line numbers may not match the source.

The application is loaded into WinDbg either by specifying &quot;windbg &quot; on the command prompt or by starting WinDbg from the program group and specifying in the Program Open dialog box (from the Program menu, choose Open). Note that is the name of the application, not the DLL. It is not necessary to specify the name of the DLL to be debugged.

The DLL is loaded either when execution of the application begins or dynamically through a call to LoadLibrary. In the first case, simply press F8 to begin execution. All DLLs and symbolic information are loaded. To trace through the DLL code, breakpoints can be set in the DLL using a variety of methods:

 From the Debug menu, choose Breakpoints. The dialog box is Program Open. Open the source file and use F9 or the &quot;hand&quot; button on the toolbar.  Go to the Command window and type:

bp[#] 

:

addr break at address

@line break at line 

In the case that the DLL is dynamically loaded, pressing F8 causes all other DLLs and symbolic information to load. The same methods described above can be used to set breakpoints; however, the user will get a dialog box indicating that the breakpoint was not instantiated. After the call to LoadLibrary has been executed, all breakpoints are instantiated (it is possible to note the color change if the DLL source window is open) and will behave as expected.

To set a breakpoint in a DLL that is not loaded, specify the context when setting the breakpoint. The syntax for a context specifier is: "{proc, module, exe}addr" "-or-" "{proc, module, exe}@line" Example: {func, module.c, app.exe}0x50987. The first two parameters are optional, so {,,app.exe}0x50987 or {,,app.exe}func could be used instead.

For example, assume that we are trying to debug a File Manager extension under Windows NT that has been built with full debugging information. The procedure to debug the extension is as follows:


 * 1) Open a Command window.
 * 2) Start WinDbg WINFILE.
 * 3) Set a breakpoint on FmExtensionProc.
 * 4) At the Command window, type g and press ENTER. The debugger will continue executing the program form the point where it stopped (which could be from the beginning, at the breakpoint, and so on).

WinDbg will start WINFILE and when FmExtensionProc is executed, WinDbg will break into the WINFILE process. Additional query words: 3.10 3.50 4.00 95

Keywords         : Version          : WINDOWS:3.1,3.5,3.51,4.0 Platform         : WINDOWS Issue type       :
 * }