A road named NoNameUno

Time to digress from the Tools and Tricks of the Trade ...

For few months, I've been tackling a very largish software (400,000 plus lines of codes). Quite a bit of it in user space, thank god!. And there are quite a bit in the kernel mode space. It is one of the toughest client/sever application I ever dealt with. A bunch of competent software engineers wrote and integrated over a period of 5 to 10 years. Beauty of this software is that it has lot of extreemly powerful features ( fault tolrance, resouce balencing, message passing infrastructure with delayed and priority queuing, some transaction models and what not). Beast of this software is how it was integrated with different components. The  communication interfaces between these modules are not terribly bad, but hundreds of global variables to track states. And there are times when 20 concurrent threads are not unusal.

So this is one example I've seen so far that is good for studying concurrent programming in action. It uses a whole lot of techniques I learned some 20 yrs back when in graduate school. But what I learned from my prior background in Mathematics that laws, formulas, theories are there to guide, not to obstruct you. So use in a way as if you are cutting cheese, not bringing down a multi-story building... Yes you can very well tell if something is hacked out or not, it does not matter who designed it, who wrote it, who debugged it...  IF YOU HAPPEN TO READ THIS ARTICLE, AND EVER GAVE SOMETHING ON FACEVALUE, stop doing that...

Now how do you analyze this kind of software, and try to make the best out of it... Yes a solid debugger is friend here. You do path analysis to find some taste of it. So I need a kernel mode symybolic debugger that is not scared to do user mode debugging. Softice used to be great in that space. I've used it to debug 16bit to 32bit user mode to 32bit kernel mode software. But now they would not have any support for 64bit, and they are phasing out. And I was not very successful with Windbg, but I'm getting a bit of return from using it. I don't like it in this particular situation, but what can I do?

If you are familiar with windows SCM, it has a requiremnt of 30 sec ( or some small epoch) for service to return to its requests. So if you use the specified approach to debug services, you will do all the song and dance with registry entry to do service debugging, and that too after the SCM interaction, and there would be no way to step into the kernel mode debugging.  This is I call the "Debugger is running for user mode debugging". Alternatively, if you put a hard break point ( like int 3 or some api's that does it for you ), and if you turn on the kernel mode debugging ( using boot.ini or other boot time features), you will  break into your service while your debugger is working with all its kernel mode capability. You step between user and kernel mode at will.  But I found sometime it works like magic, some other time it is all wet. And also not recommended to be used that way ( as far as I know).

I wish I could talk to windbg ( just like hi fi movie theme)....

Me> Hey Windbg, can you be a debugger that move between user mode and kernel mode ???

Windbg> I'm thinking ( Tobe or not to be) ...