Setting up visual studio c++ debugger to support s

Question

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).

Answer 1

Although your title says "Visual Studio", in your question and in the comments, you mentioned that a WinDbg solution would also help, if the process can be automated. So this is a WinDbg answer.

Symbol path

WinDbg knows the concept of workspaces. You won't get it until you read and exercise Uncovering how Workspaces work with WinDbg [MSDN blogs]. Once you know how they work, set up the base workspace to include your favorite symbol path.

Once you're satisfied with the workspace, create a link for WinDbg to include -Q: suppress the annoying "Save workspace?" question.

As an alternative, you can pass the symbol path using the -y <SymbolPath> command line switch.

Or, if the command is just too long, use the shorter and more comprehensive form

.sympath c:\mySpecialSymbolsDir
.symfix+ C:\Symbols\MS\

Running commands at startup

To run a command at the start of WinDbg, use -c "<command>". This should e.g. be fine for a .reload. If you want to run many commands or complex commands (especially when quotation marks are involved), look into Run script file [MSDN].

Other

Depending on whether you're doing live debugging or crash dump analysis, you might want to use more WinDbg command line options [MSDN].

Things that could be useful in your situation:

-pn <name>: Debug a process by name
-<executable>: Start the executable instead of attaching.   
-z <dump>: Debug a dump file
-srcpath <path>: Path to your sources

Answer 2

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.