I found a very strange bug with a kernel driver I do some work on this last week. It only seems to appear when we have GoogleDesktop or the MSN Desktop Search installed. After some period of time the graphics display just starts doing some whacky stuff: fonts don’t display, repaints don’t work quite right, just general whackiness.
So since this is only happening after some period of time on a machine, we started looking at resources. Using the pooltag tool from sysinternals we found one particular tag that looked out of control. The tag was FSrN, which according to the lists I could find is “File-system runtime”. Helpful, no?
So that brings me to the meat of the story. I wanted to find out who was allocating that and what the call stack looked like at the time. In order to do this I needed to put a breakpoint on ExAllocatePoolWithTag, but that gets called ALL the time. I only wanted to break when we hit the right tag value. So I came up with the following command to set the breakpoint in windbg:
bp nt!ExAllocatePoolWithTag “j (Poi(ss:esp+c) = ‘NrSF’) ‘kb; db ss:esp+c’; ‘gc’ “
You can check out the windbg help for more information on conditional breakpoints. It will explain what the above command means. I wanted to post it since I couldn’t find any good example of how to do this with a non-integer value.
Thanks for this post. I was looking for some help regarding the same. Could you please explain, how did you arrive at “ss:esp+c” for Pooltag allocation. Please include all the steps that you took to arrive to this breakpoint.
Regards
Pushkar
Well, arriving at the address I wanted to look at was actually pretty simple. I initially set a breakpoint on ExAllocatePoolWithTag with no conditions. When I got the first break, I looked at the stack (which is essentially what the esp register is pointing at). I knew that the parameters to the function call would be on the stack (or depending on the compiler, calling conventions, architecture, etc. they could be in registers). So I just found something that looked like a pooltag and used that offset. You could also break on your own process so that you KNOW what pooltag you’re looking for, which makes it a bit easier to find.
So basically, the methodology is just break where you want to look at things, and then poke around until you find something interesting. 🙂 And of course, knowing information about how the compiler builds and passes parameters helps things along. The more you look at stuff like this, the easier it becomes to find.
Thanks a Ton! I was looking for this primer. I have been doing some poking around with the debugger, but digginging into Assmebly was little difficult. Your post and answer helped me with a better understanding.
check out .if
..much easier to remember!