We used to enter the module name + :: + variable name and that worked in older times. I'm not sure if it is the code versions being used or the fact the modules are in a dll that is the issue. But it makes debugging hard, and I could find any discription of how this works in the documentation. Can you point me to documentation that explains how to do this? And hopefully explain here what to do. We just get "undefined variable" alot. We see this a lot in subroutines, where we can't view local variables with quickwatch or watch. THere seems to be lots of scoping issues and again it makes debugging difficult.
The debugger cannot locate a variable in a module within a DLL until after the DLL is loaded. What I typically do to aid debugging is to add an innocuous subroutine "FindMyDLL" that does nothing (and is not optimized out). I place a call to this in the beginning of the program, and then step into it. Once there, then the DLL is present and the address can be resolved.
If the :: cannot resolve the name, try
For break on condition (e.g. write to location), get the address of variable by using Memory Watch, copy address to paste buffer, then:
Debug | Break Points | Add New | Add data break point | C/C++ | paste in address | number of bytes 4 or 8
I've had issue with entering the symbolic name in the data break location edit box.
Unfortunately this is durring program execution. So the DLL has been loaded and used. I do this while at a breakpoint in the execution. In a routine where the module has been used, but the variable within the module isn't referenced. Using YourModuleName_MP_TheVariableName or even the __imp_ version listed in the .map file. The ties to the Microsoft products used to do all the debugging seems to be very weak. Changes and breaks often with new versions, while most of this used to work. Some support from Intel in this area to use the code would be appreciated.