In the original prolog of the Debugging STL Containers with WinDbg series, I started off with a simple main.cpp source, compiled it with the Visual Studio compiler, and debugged the executable with WinDbg.
A few folks mentioned that there ought to be some info that covers the steps from having an executable to seeing the debugger output. I had the assumption that if readers were interested in those blog posts they’d probably have some experiences with WinDbg. But I do agree that no matter how trivial some things might be, documenting the exact steps could be helpful one way or the other.
So here are my steps.
1. Prepare the Operating System, Compiler, and WinDbg:
a. Install Windows 8 Version 6.2 Build 9200.
2. Open a Visual Studio command prompt.
In Windows 8, press Windows logo key +Q, and type “Developer Command Prompt for VS2012”. Select the resulting app.
Here’s what my command prompt looks like where I create main.cpp:
3. Write some code in main.cpp. Here’s an example:
4. Save the file, and run the following command to compile it:
5. Start WinDbg. In Windows 8, press Windows logo key +Q, and type “windbg”. Select “WinDbg (X86)”.
6. In WinDbg, press Ctrl+E (or go to File..Open Executable), type in C:\Projects\STL\main.exe for File name, and then click the Open button. If you receive a Workspace prompt, click Yes to save information for workspace.
7. Type in the following commands, one after another, in WinDbg:
.reload /f ntdll.dll
.reload /f kernel32.dll
At this point here’s what your WinDbg Command window might look like (I’ve highlighted the commands you need to type in):
Here’s a sample picture of it:
Here’s what happened:
!sym noisy – Activates noisy symbol loading so that when the debugger loads symbols you get more details like exactly where the symbol was loaded.
!symfix c:\symbols (or .symfix) – Sets the symbol path to point to Microsoft symbol store. I specified c:\symbols to store downloaded symbols there.
.reload /f ntdll.dll and .reload /f kernel32.dll – Since when this debug session starts I didn’t have proper symbol path set, symbols for these two modules were not loaded. After I set the symbol path with !symfix, I’m manually reloading the symbols for these two modules. This is not necessary in this specific case but in general it’s a good practice to have symbols for these two modules.
bp main!main – Sets a breakpoint at main().
g – Go (F5), just like what you’re accustomed to in Visual Studio.
8. At this point you can just press F10 or the Step Over button on the toolbar to step over the source code until you hit the for line. This is where the code added three elements into the vector.
9. Now in the debugger’s Command window you can type commands like dt ss to look at the vector:
There you go. The steps that accompany the rest of the series.
You know what, actually I’m glad I wrote these down. I might need to reference these sometime later myself.
P.S. I was tempted to go back to the prolog and add a section with an “Update” label. Sounded logical, but I didn’t want to bloat that blog post into a book. Hence this post, Prolog 2. I’ve tagged this post with the same tags as the other posts in the series, so at least the tag cloud works as it’s supposed to. There are so many other questions that could spawn from this little post, like “why not use Visual Studio to create main.cpp”, “why X86 and not X64”, “why c:\symbols and not d:\symbols”, or even “why Windows 8 and not Windows XP or Windows 7”. I’ll re-evaluate the need to expand on these points at a later time 🙂
P.P.S. Just a gentle reminder, if you’re still using Windows XP. Its support ends on April 8, 2014!