Sharpen the Saw
Gather round, young’ins, Grandpa Eric is going to tell you a story.
Back in the old days, when I started writing software, programmers’ utilities were sold in boxes in retail stores. You’d plunk down your 149 bucks or whatever (in cash, kids, this was before credit cards got popular) and you’d get your cardboard box full of floppies (or maybe a CD, if you were cutting edge) and a manual. If you wanted to save a few bucks, you might hunt for a paper catalog or classified ad in a programmer’s journal and find a mail-order house to order from. You’d fill out a form, enclose a check, and wait a few weeks to get your box.
Now, when I say you got “a manual”, I’m talking about the real deal, a book a few hundred pages long, crafted with care to explain how to make use of what you’d bought. This wasn’t at all like what you get today if you happen to buy software that ships from Amazon or whatever, which usually consists of a little leaflet of disclaimers written by the lawyers, and maybe a little picture showing how to put the CD in the computer. Nor was a good manual like most of today’s online help files, which consist of what seem to be printouts of the functional spec. No, you got a book, which was thorough and written with the expectation that it would be read. The chapters would be logically organized, and usually included more than just the basics, giving examples, tips, and oftentimes, some little jokes or other signs that a human being was actually involved in the production. A good manual reinforced the developers’ pride-of-craftsmanship—if it was too awkward to write an explanation of how to use a feature, the embarrassed developers would be forced to redesign the feature, if only to allow the manual to pass the giggle-test.
Things have changed in the last 15 years. These days, you just launch your browser and download your indispensible utilities, free of charge, in less time than you’ve spent reading so far. But something was lost in this paradigm shift, which is why I was so excited to hear that the legendary Mark Russinovich had teamed up with all-around-smart guy Aaron Margosis to put together an honest-to-goodness book, a guide to the Sysinternals toolset. Titled Windows Sysinternals Administrator’s Reference, can get it for your Kindle, or as I did, in old-fashioned dead-tree format, suitable for scribbling in and dog-earing to your heart’s content. I’ll admit that the title had me a bit worried (I don’t want to administer anything, really), but I’m guessing that their publisher wouldn’t let them name the book more aptly (e.g. “Using Sysinternals Tools to Demystify Shi^H^Hoftware”)
Now, for the rare techie who’s not already a big fan of the Sysinternals tools, I’ll give a bit of background. The collection includes around 70 freeware utilities grouped into six loose categories (Process Utilities, Security Utilities, File and Disk Utilities, Networking Utilities, System Info, and Miscellaneous) the majority of which run on any version of Windows (XP and later). I’ve been using several of the tools on an almost daily basis for a decade. I use Sysinternals utilities to deeply understand the guts of every product I’ve ever worked on, and to resolve problems with many pieces of software I otherwise know little about..
One of the perks of working in the Windows division at Microsoft is access to the source code of every version of Windows we’ve shipped in the last decade, but when I want to understand how our software works, I turn to Fiddler and the Sysinternals tools. Why? Because these utilities tell you the truth and show what’s really going on. Source code is super-useful, of course, but it’s often much more challenging to dig through—there are tens of millions of lines of code to sift through, and they interact in ways that were never formally documented, and sometimes, we find, ways that were never intended. The advantage of using monitoring utilities is that you get to see what’s happening, and that usually brings you 90% of the way to a solution. The ability to “peek inside” software as it runs is astonishingly empowering-- in the same way that xrays and MRIs have had a huge impact on the practice of medicine.
Just booting Fiddler or Process Monitor and watching the events fly by will provide a non-trivial level of insight into how software on your computer works. But there’s a difference between toying with these utilities and fully exploiting their power, and this is where Mark and Aaron’s new book comes in. The book covers each of the tools and provides a full explanation of each; the two most useful tools (Process Explorer and Process Monitor) each get a chapter all their own, but even the most trivial of the utilities in the collection gets a page of coverage.
As a developer myself, my favorite parts of the book are where the authors reveal some of the tools’ “secrets”, explaining how they accomplish some interesting task. For instance, Process Explorer can be configured to replace the native Windows Task Manager—a non-trivial exercise unless you know the clever trick of using Image File Execution Options to remap one executable to another. Similarly, the “Jump To Registry Key” feature used throughout the suite simply relies on sending keys to the Registry Editor window, and is thus subject to the same UIPI restrictions that prevent Low Rights IE add-ons from sending input to medium integrity applications. Lastly, I learned how the ps* Utilities are able to deliver their functionality to remote systems, despite the seeming impossibility of that task.
My other favorite parts of the book are the “Case of the… ” sections that comprise the last three chapters—each section explains how the authors (or their colleagues) have used one or more of the Sysinternals tools to solve a real-world problem. These sections are well-written, super-interesting, and provide a fantastic primer for turning what you’ve learned in the earlier chapters into real-world results.
The book includes tons of facts about Windows itself that I’d forgotten or never picked up on to begin with. For instance, over the last half decade I’ve wondered about the “phantom” C:\Documents and Settings\ folder on Vista+ machines. I correctly guessed that the folder was still there for legacy compatibility reasons, but didn’t understand how it enhanced compat, since attempting to navigate to the folder somehow fails. Thanks to the book, I now know that this is a NTFS Junction pointed at C:\Users, but it is configured to deny the List Files permission while allowing all other permissions. In this way, a legacy application can read or write a specific file inside C:\Documents and Settings\, while blocking the user from explicitly navigating into that path. Similarly, I learned that the 32bit “WOW64” subsystem can be uninstalled on the Core SKU of Windows Server, an interesting configuration tidbit for developers of any tool that includes 32bit components.
Over the years, Windows has added a number of features previously only available in the Sysinternals tools—the authors mention when this is the case, and compare and contrast the new Windows features to those in the Sysinternals utilities. For instance, on Windows 7, the command powercfg /energy (see pg 375) generates a super-interesting report that I didn’t even know existed.
No book is perfect, of course. The book’s structure enables the reader to jump directly to information about each specific tool, so anyone who reads the book cover-to-cover as I did will find some repetition of information between the sections and chapters. The authors’ expectations of their readers’ technical-savvy also seems uneven at some points—I was amused that a book that discusses kernel debugging and memory-manager design would take the time to footnote the meaning of the word “string” as it is used in software. But, on the whole, the book is very well-written.
As of this writing, the Windows SysInternals Administrator’s Reference will set you back less than thirty bucks and it’s worth every penny—heck, you could probably buy the EBook and a Kindle for less than this class of product would have sold for in the 1990s. Sure, you can just download the tools for free, but I guarantee you’ll get more out of them if you read the book. If you develop or debug software on the Windows platform, this book will provide a great return on investment (purchase price and reading time).
-Eric Lawrence
Comments
Anonymous
August 15, 2011
Does the book have any useful content for a programmer that has been using the Sysinternals tools for years? I know pslist uses remote registry, is there ANY other useful information for me in this book? I don't need a listing of command parameter descriptions etc...Anonymous
August 15, 2011
@asf: As I mentioned, I've been using the tools for many years, and as I mentioned, I've been writing code for a long time. The ps* utilities rely on a lot more than the remote registry, the full explanation of which is, as I said, one of the reasons I found this book interesting.Anonymous
August 16, 2011
Great review. I was considering purchasing this and now I'm convinced.Anonymous
August 18, 2011
what we really need is a Fiddler reference :)Anonymous
August 18, 2011
@anonymouse: I've been trying to guess whether a market for such a book exists. I'd love to write one.Anonymous
August 21, 2011
@EricLaw: Based on the activity in [fiddler] tag on StackOverflow, and on my meatspace experience, the market exists, IMNSHO - Fiddler is polished and intuitive in its basic operation (thank you for the great tool, it has helped me immensely, countless times), but although I have been using it for several years, I keep discovering useful bits of functionality - be it in Fiddler, or FiddlerScript (I haven't ventured into FiddlerCore yet); and usually it's not a recently-added feature, meaning I just didn't notice it.