Debugging DLLs Using WinDbg

 Last reviewed: November 2, 1995
Article ID: Q97908
The information in this article applies to:
  • Microsoft Win32 Software Development Kit (SDK), versions 3.1, 3.5, 3.51, and 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 "More Information" 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 "windbg <filename>" on the command prompt or by starting WinDbg from the program group and specifying <filename> in the Program Open dialog box (from the Program menu, choose Open). Note that <filename> 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.

    -or-

  • Open the source file and use F9 or the "hand" button on the toolbar.

    -or-

  • Go to the Command window and type: 

           bp[#] <Options>

    <Options>: 

          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 reference words: 3.10 3.50 4.00 95
KBCategory: kbtool
KBSubcategory: TlsWindbg

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: November 2, 1995
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.