Ian Reay

Here is a great overview of the fiddler http debugger.

http://west-wind.com/weblog/posts/596348.aspx

Major points include:

1. Intercepting general http traffic for IE
2. How proxies can be used to intercept http traffic from other browsers.
3. Intercept/Debug web service traffic

Mark Russonovich

• http://www.microsoft.com/emea/spotlight/sessionh.aspx?videoid=993
  • Discusses the various security boundaries and outlines which ones are hard and which are soft.

Rafal Lukawiecki

• Introduction to Data Mining (Video Presentation)
  • This is the first of 5 presentations given by Rafal on the topic of Data Mining. A great crash course in a rapidly developing technology sector.

Microsoft Advanced Windows Debugging and Troubleshooting Blog

• Basics of NT Debugging
  • Discusses debuggers such as ntsd.exe, cdb.exe, and windbg.exe. A great post for anyone getting started in native windows development.

Jonathan Edwards

•  Too Many Cores, Not Enough Brains
  • A very interesting take on the whole Concurrent Programming movement in software development. Argues that “Giving a multicore CPU to a programmer is like giving a drink to an alcoholic” which do agree with to a point ;). People developing concurrent applications should at least be aware of this critique.

Mark Roberts

• Advanced Debugging Techniques With Visual Studio
  • A solid crash course on native debugging. Discusses how symbol and source servers can aid debugging. Tips and tricks for x86, x64, optimized debugging techniques.

Nynaev

• Why hooking system services is more difficult (and dangerous) than it looks

Microsoft Advanced Windows Debugging and Troubleshooting

•  What are the odds?
  • Discusses the thought process used when tracking down defects in one component which manifest as a failure in another, sometimes distantly related, component.

Herb Sutter

• Constructor Exceptions in C++, C#, and Java
  • Herb discusses issues related to throwing exceptions within an objects constructor and why this can be extremely dangerous. All developers using libraries which throw exceptions must be familiar with how exceptions affect object and member component lifetimes.

Andrei Alexandrescu

• Memory Allocation: Either Love It or Hate It. (Or Just Think It’s OK.) (Video Presentation)
  • Gives good arguments for when you should, or should not create your own memory allocators in C++. Andrei also describes the basic functionality of heaps and the run time overheads associated with them.

Bartosz Milewski

• The C++ Memory Model (Video Presentation)
  
  • Bartosz discusses the C++ memory model in depth. Why the current model isn’t appropriate in multi-threaded applications (especially cross platform applications) and how C++0x plans on resolving these issues.
  • I found this really eye opening. I was not familiar with how processor optimizations with respect to memory writes can create such pervasive race conditions.
  • For all of you who think c++ pointers are difficult, your going to be in for a rude shock. In addition to determining where your data is stored, you must now specify when it will be stored.

Sounds like a straight forward question that should have a simple answer. I bet your thinking it’s not even worthy of a blog post? At first glance, I would tend to agree. Just run your program in the debugger. Unfortunately, there are many ways of doing that and no one approach is optimal for all the debugging situations you may encounter.

Here is a list of a few ways that I know of that can be used to get into the debugger

1. Start the process in the debugger (ie, windbg.exe my_program.exe)
2. Start the process in the debugger using the Image File Execution Options registry keys provided by windows.
3. Attach the debugger to an already running process.
4. Attach a kernel debugger to a specific instance of the program you are running.
5. Compile DebugBreak() call’s into your code
6. Compile an Int 3 assembly instruction into your code.
7. Compile conditional DebugBreak() or Int 3 calls into your code.
8. Cause a controlled access violation in your code which you then step over.

It’s very possible that I’m missing several methods but at least this is a start ;).

I plan on creating a unique tutorial for each one of these approaches. The goal is to highlight the strengths and weaknesses of each approach which I have listed in order of preference (sort of). I really don’t like debugging techniques that involve modification of source code and recompilation. It’s often far faster (and easier) to get your process into a debugger and set breakpoints where appropriate.