After the last part the mindbg debugger stops at the application entry point, has module symbols loaded and displays source code that is being executed. Today we will gain some more control over the debugging process by using breakpoints. By the end of this post we will be able to stop the debugger on either a function execution or at any source line.
Continue reading Writing a .net debugger (part 4) – breakpoints
In this part I will show you how to load module debugging symbols (PDB files) into the debugger and how to bind them with source files. This can’t be achieved without diving into process, thread and module internals so we will examine these structures also.
Continue reading Writing a .net debugger (part 3) – symbol and source files
In this part I will describe which events the debugger has to deal with and how it should respond to them. Additionally we will create few COM wrappers for ICorDebug* interfaces. Let’s first examine the ICorDebugManagedCallback interface (imported from COM object – more in part 1). You may notice that each event handler has its own set of parameters, but the first parameter is always of type either ICorDebugAppDomain or ICorDebugProcess. Both ICorDebugAppDomain and ICorDebugProcess implement ICorDebugController which allows you to control the debuggee.
Continue reading Writing a .net debugger (part 2) – handling events and creating wrappers
After having analyzed the mdbg sources I decided that the best way to learn how the .net debugging services are working will be to implement my own small debugger engine (named mindbg). In a series of posts I will try to explain each part of the debugger engine (such as starting/stopping debuggee, setting breakpoint, walking the stack etc.). The whole project is hosted on codeplex and you may access the sources here.
Continue reading Writing a .net debugger (part 1) – starting the debugging session