WinDbg: conditional break-points to the rescue

I work on a large .NET based application and although I have access to all the source code (million lines of source code) it is somethimes not easy to pin point a problem. One approach that has been helpful over time is to use the debugger and set a conditional break-point.

Our test systems are not equiped with Visual Studio so most of the time I use WinDbg (which I alway easily can install from my USB drive). In this particular case I needed to figure out which piece of code was opening a particular file (I knew that the problem I was looking at was related to this file by using one of my other favorite tools Xperf).

So after installing WinDbg and setting up the system I attached the debugger and loaded the sos debugging extension (.loadby sos clr OR .loadby sos mscorwks if you are still on CLR 2.0).

Then I set the break-point:

bu KERNEL32!CreateFileW ";as /mu ${/v:fileName} poi(@esp+4); .if ( $spat( \"${fileName}\", \"*test*\" ) != 0 ) { du poi(esp+4);!clrstack; g } .else { g }"


This breakpoint does the following:
- Break on a call to CreateFileW (also used for opening files)
- stores the name of the file that needs to be opened (including the path) into the alias 'fileName'
- Checks if the filename contains a certain pattern (in this case *test*) and if so:
- show the filename
- shows the calls stack
- continue the execution

I then executed the particular test case to get a repro. The debugger output led me right to the code opening the file.

You can apply this technique to many other problems. For example you can figure out who is creating threads or who is allocating large blocks of memory.

Happy bug hunting!