Debugging Windows

Many times my friends ask, how do we debug windows.
You must have debugged your own code many times.(People from non-coding community are not welcome to this blog). All you do is launch the exe in debug mode in visual studio or gdb , put a breakpoint on the concerned place which you doubt the most to be flunking, and the execution stops right at that place.
But then, think if I do the same to windows. Windows stops!!Whoaa!!! Do you understand what does this mean. Even your visual studio stops because it is working 'above' windows.
Add to that the fact that this windows is millions of lines of code. Guess which function you would put the breakpoint on, if a particular file deletion process is not working fine. Since, there are thousands of project running in millions, I wouldn't delve into how such things and debugging them is managed(through componentization).

Windbg is a very common tools for people debugging, understanding, troubleshooting and hacking windows.
This is a very handy and useful tool to debug any application, where you cannot use the conventinal method of debugging. There is a code project article which can be useful for beginners and budding hackers to understand what exactly goes on while you are clicking a mouse button in windows.

The most common complaint of windows users is their 'view'(actually explorer.exe, Ok, budding technocrats who are yet not comfortable with tech terminologies are welcome here :p) hangs. Or the crash where you get the option of "send" or "don't send" and most of the time you click "don't send". Well this is actually the watson window crash. When you decide to send it, the 'state' of your machine is sent to Microsoft where engineers are engaged to find out why it happened so that this can be corrected in the next product cycle.

But this might also happen when there is a third party (non-MS) software installed on the machine. Or there could be a virus which is screwing up your machine. If you know that you are getting this window very often, the best thing to do is
1. 'Attach' debugger to the process or service which you think might be screwing it up.
2. Continue with your normal operation
3. The moment there is a crash, ie, the ugly watson window is about to come up, the process will 'break' into debugger and you can now 'watch' it. You can also see what happened
4. Hit 'k' command in debugger to see the stack trace and know which binary is flunking.

If you get a windows binary in top of stack and doubt that windows is screwing you , you can download the public symbols. More information is found here. Information about how to configure the debugger(windbg as well as any other debugger) is found here.

All that I have said above is valid only for user mode debugging. For kernel mode debugging, needed for developers writing drivers, file systems or implementing their networking wrappers you need two machines. The debugee having a com-port and a debugger where you will have the windbg and symbols. You will need a COM cable to connect the machines.
After that once the debugger is able to connect to the debugee, you can virtually move through all the kernel mode objects, handle tables, thread switching, memory allocation data structures. The driver you are writing can be debugged here.