Search code examples
visual-studiodebuggingwindbgvisual-studio-debugging

Setting up visual studio c++ debugger to support symbols for modules loaded from memory

Im using the following code to load a DLL from the memory onto another running executable. debugging the following module with the common methods wont work as the debugger is unable to locate the appropriate PDB files, not to mention make it aware that the DLL was actually loaded to the process. i managed to set it somehow working with windbg by:

  1. specifying the debugger where the module is located in the memory and its length using .reload [DLLLocationInMemory]=0x10000000,[DllSizeInMemory]a48194
  2. re-arranging the symbols server .sympath SRV*C:\Symbols\MS\*http://msdl.microsoft.com/download/symbols;c:\mySpecialSymbolsDir
  3. running the show

doing so each debugging iteration is quite annoying, i was wondering if something similar could be done using visual studio's debugging window(especially step #1).

Solution

  • You can run .imgscan /l to find all modules in memory and de-facto .reload them.

    (What this meta-command basically does is search for “MZ” on all page-aligned addresses. For every “MZ” it finds, it tries to interpret the data starting at this address as a DOS_IMAGE_HEADERS struct, takes the e_lfanew field of the struct, goes to where it points and assumes there’s a PE header (NT_IMAGE_HEADER) there. Then it goes to the SizeOfImage field of the IMAGE_OPTIONAL_HEADER part of the PE header. Then it calls .reload ModName=AddressOfFoundMZ,SizeOfImage. I’m not sure whether or not you’ll get a meaningful name for a module loaded the way you load them.)

    You symbol path should be a part of a workspace or set in the environment variable _NT_SYMBOL_PATH (or use a command-line parameter for WinDbg as Thomas suggested). This is true regardless of whether you debug a DLL loaded normally or in the way do, and regardless of whether you use Visual Studio or WinDbg.

    I very much doubt that's possible in Visual Studio. I know of no such option in the Modules Windows in Visual Studio, and given that Visual Studio by design does not allow loading mismatched symbols I don't see it allowing you to declare "well, you see this memory region - assume that's a DLL there..."; that's exactly what WinDbg is for.