Diagnosing Windows Woes

There is a minor "Windows vs *nix" debate going on in the U2 forum this week. I don’t really want to enter the debate. To me it’s important that people just have good information for making their decisions, that they know what resources are available to help them get around issues that they say are high priorities for them. I hope the brief notes here will help.

Some people prefer to find and fix issues rather than just accepting and complaining about them. For these folks, the (completely free) Sysinternals utilities are absolutely required tools for any shop that maintains Windows servers – though most people don’t seem to know they exist or how to use them. If you think you know about these tools, take another look because I’ll bet there is a lot in there that you knew nothing about. Mark Russinovich, author of those tools and a really impressive technician, was assimilated by Microsoft (resistance is futile) and he and all utilities can now be found here.

Whether or not you think you can use the tools yourself, I recommend you take the time to go over Mark’s webcasts and you will see that the tools available can help you to diagnose performance issues and corruption that are otherwise "just one of those things" that drive people to *nix. If you don’t understand the tools (it’s very heavy stuff), get your other IT colleagues to go over them. But once someone in your organization "gets it" I think you will come to rely heavily on the (completely free) utilities – and you’ll feel a lot better about your systems as well.

I don’t pretend to be qualified for Windows server maintenance or to diagnose chronic performance issues, etc. I don’t have a big environment that requires constant attention to such things. But the few times I’ve had to get "deep" with the Sysinternals utilities, I had very good results finding things that I just didn’t know about before.

Warning to software vendors

If you have customers who start to use Sysinternals utilities, they will start to ask you "deep" questions like why a specific DLL is consuming a certain amount of memory, or why your file operations aren’t more optimized, or why you’re not caching data rather than reading it from disk every time. You can learn a lot about your own code from these tools, and you might even get some marketing points for telling people that you’re using these sophisticated tools to improve your product.

I hope this helps someone.