Here you can view some example screenshots, which show various situations during debugging a simple program on remote Linux host using WinGDB.

Please pay attention how the data which has been read from the remote GDB backend is presented inside native Visual Studio debug windows. It looks n' feels just like a normal Visual Studio debugger.

Click on each image to view larger version.

You can see several frequently used debug windows in action. The code is just about to open a dynamic library, the result can be seen on the next screenshot.

You can see that the dynamic library libfoo.so has been opened (look in the Modules window). The debugger has stopped on a breakpoint inside some function in that library. You can set breakpoints even before loading a library, as recent GDBs support so-called pending breakpoints and WinGDB makes use of them.

The dynamic library libfoo.so has been closed, so it has disappeared from the modules list. You can also see how the call stack window changes. Another important thing is the process input/output console, where we can see output generated by program as a result of printf call. The console aims to support full VT100 terminal command set.

Here you can see an example of stepping through assembly code in parallel with source code. The disassembly view has been configured to disable symbol labels and binary code view.

This time there is also the Registers window present. It shows an additional feature that Visual Studio offers for all expression windows: special coloring of recently changed values. It works seamlessly with WinGDB.

Now the Disassembly window has some extended features enabled (symbolic locations and binary code view). There is also the Breakpoints window at the bottom, showing the possibility of managing breakpoints also inside assembler code. We can set breakpoint at any location which has an address. It doesn't have to be the first assembly line related to source code of high-level language.

You can see the memory window with address set to &hLibrary, which is the first variable on stack (second is 'fn', and third is 'result'). Below the locals window is located, displaying all these local variables. These values are visible in the memory window in binary form.

The memory view has been set to 4-byte words. You can see the environment block of the process and a fragment of the stack area.

There is straight sample - iteration through current directory. You can see that Locals and Autos windows are automatically filled after each step. Values changed after last step have other color. There are complex structures - you can expand/collapse them according to your needs.

You can see breakpoints with their additional properties (hit count/condition). There is data breakpoint too (write-watchpoint in gdb nomenclature), it is set for address equal to '&result'. Program stopped when value of variable 'result' has changed. In right panel you can see watch window.

Here you can see popular file commander in WinGDB process console. The program has been stopped by 'Break All' command when 'Find File' dialog was active.