Recently, in a dynamic library, this dynamic library is the executable to dynamically load during the execution process, so set a breakpoint in the dynamic library code. When startup, there will always be a breakpoint invalid warning, and The breakpoint becomes gray, only when the dynamic library is loaded, it can set the breakpoint.
I have been looking for a half day in MSDN and finally find the solution:
Can't set Breakpoint in Source File When Corresponding Symbolic Info isn't loaded Into memory by debugger
You can not 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 can not be set" or a simple, non-informational beep. When setting breakpoints before the debuggee 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 designated debuggees and then walks through its breakpoint list, attempting to . set the breakpoints However, if one or more of the debuggees 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 ole Server Before. Other Similar Cases.
NOTE: After you receive notification that these breakpoints can not be set, the breakpoints will usually continue to show up in the breakpoint list, but they will have a dash (-) to their left, indicating that they are disabled (have not been set) . to prevent this behavior in Visual C , specify all additional DLLs and OLE servers in the Additional DLLs field in the Options.Debug ... dialog box. to prevent this behavior in in CodeView, use the / L command line switch to notify CodeView that you want it to Load symbolic debug information for additional .EXE and .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. Ensure that these additional debuggees are not already running when you start your debugging session. Failure to follow this rule will likely cause breakpoints to be missed. document says the solution is to set the Additional DLLs Middle designation needs to be loaded Dlls. If you don't have your brain, let me catch a half day, and finally I finally discovered that in the Project-Settings's Debug tab, select Additional DLLS for Category, haha, enter the name of the DLLS that you need to load in the modules below. You can
