Why Don’t My DLL Breakpoints Work?
Some reasons why your breakpoints don’t work as expected are listed here, along with solutions or work-arounds for each. If you follow the instructions in one topic and are still having breakpoint problems, look at some of the other topics. Often breakpoint problems result from a combination of conditions.
You can't set a breakpoint in a source file when the corresponding symbolic information isn't loaded into memory by the debugger.
You cannot set a breakpoint in any source file when the corresponding symbolic information will not be loaded into memory by the debugger. Symptoms include messages such as "the breakpoint cannot be set" or a simple, noninformational beep.
When setting breakpoints before the code to be debugged has been started, the debugger uses a breakpoint list to keep track of how and where to set breakpoints. When you actually begin the debugging session, the debugger loads the symbolic information for all the code to be debugged and then walks through its breakpoint list, attempting to set the breakpoints.
However, if one or more of the code modules have not been designated to the debugger, there will be no symbolic information for the debugger to use when walking through its breakpoint list. Situations where this is likely to occur include:
Attempts to set breakpoints in a DLL before the call to LoadLibrary.
Setting a breakpoint in an ActiveX server before the container has started the server.
Other similar cases.
To prevent this behavior in Visual C++, specify all additional DLLs and COM servers in the Additional DLLs field in the Debug/Options dialog box to notify the debugger that you want it to load symbolic debug information for additional .DLL files. When this has been done, breakpoints set in code that has not yet been loaded into memory will be "virtual" breakpoints. When the code is actually loaded into memory by the loader, these become physical breakpoints. Make sure that these additional debugging processes are not already running when you start your debugging session. The debugging process and these additional processes must be sychronized at the same beginning point to work correctly, hitting all breakpoints.
Breakpoints are missed when more than one copy of a DLL is on your hard disk.
Having more than one copy of a DLL on your hard drive, especially if it is in your Windows directory, can cause debugger confusion. The debugger will load the symbolic information for the DLL specified to it at run time (with the Additional DLLs field in the Debug/Options dialog box), while Windows has actually loaded a different copy of the DLL itself into memory. Because there is no way to force the debugger to load a specific DLL, it is a good idea to keep only one version of a DLL at a time in your path, current directory, and Windows directory.
You can’t set "Break When Expression Has Changed" breakpoints on a variable local to a DLL.
Setting a "Break When Expression Has Changed" breakpoint on a variable local to a DLL function before the call to LoadLibrary causes the breakpoint to be virtual (there are no physical addresses for the DLL in memory yet). Virtual breakpoints involving expressions pose a special problem. The DLL must be specified to the debugger at startup (causing its symbolic information to be loaded). In addition, the DLL's executable code must also be loaded into memory before this kind of breakpoint can be set. This means that the calling application's code must be executed to the point after its call to LoadLibrary before the debugger will allow this type of breakpoint to be set.