Skip to main content
Exploring what’s next in tech – Insights, information, and ideas for today’s IT and business leaders

Candid talk from the man behind your favorite Windows tools

Q&A: A conversation with Mark Russinovich, the creator of Sysinternals tools, used by almost everyone involved in Windows administration, development, and security

If you're involved with administrating or troubleshooting Windows systems, you are doubtless familiar with the Windows Sysinternals Tools, a series of tools, both command line and GUI, for exploring and manipulating systems, files, processes, and other lower-level system facilities.

All over the world, administrators use Sysmon to generate system log entries much more detailed than Windows provides by default. Security engineers use Process Explorer to determine exactly what is running on a system and to drill down into the behavior of those processes, and Autoruns to see which programs are set to run automatically in Windows. Developers use DebugView to capture debug output on a system anywhere on the network without having to run a debugger on it.

These tools are used not just by individual users and administrators but important Internet services. VirusTotal, a malware-checking service, uses Sigcheck to extract code signature information from files, for example.

The tools were the creation of Mark Russinovich, now chief technology officer at Microsoft Azure, and his then consulting partner, Bryce Cogswell. Russinovich is also the author of important technical books, including "Windows Internals," now in its 7th edition, and, with Aaron Margosis, "Troubleshooting With the Windows Sysinternals Tools," as well as the Jeff Aiken Series of cyberterrorism thriller novels. Russinovich was co-founder of Winternals Software, which Microsoft bought in 2006, taking him and the tools in the package.

The first of the tools was released in 1996, making 2021 the 25th anniversary. We talked to Russinovich about the tools and their impact on the Windows community.

What were the first Sysinternals tools you wrote?

The first tool that I wrote was Ctrl2Cap, which was a tool I needed as I moved from Unix to Windows. On Unix keyboards back then, the control key was where the caps lock key is on Windows keyboards. I decided instead of trying to fight my muscle memory, I would just write a driver to remap the keyboard. I was working on Windows Internals as part of a startup I founded. … Along the way, I started to develop tools to help me understand the way the operating system worked. So some of the other very early tools, FileMon and RegMon, were the first tools, which I wrote with Bryce Cogswell back in 1996 and then realized, "Hey, these tools are kind of cool for helping me understand and also I think useful for other people." [FileMon and RegMon are no longer available. Their functionality has been built into Process Monitor.] 

Who uses the tools?

Power users, IT admins, and developers predominantly. Some of the tools have different purposes that are more suitable or relevant to different audiences than others. [For example], DebugView is more useful for a developer, whereas Sysmon is for somebody working in cybersecurity. Active Directory Explorer is also used by security researchers and attackers to dump AD because you can take snapshots and then load them into AD Explorer offline.

Just about every company that I know of that has Windows uses the tools to some extent. One of the ones where I've been more directly involved is companies and organizations that use Sysmon, and there are various intelligence and defense organizations in the U.S. and around the world that have Sysmon deployed at scale.

I assume Microsoft uses them, too.

Definitely. For example, we use several of the tools inside Azure's infrastructure; like ProcDump we use on Azure's servers internally for debugging and analysis.

Why aren't they included with Windows itself?

For several reasons. One is Windows has a lot of rigor around making them address the broad Windows population in terms of, for example, multinational language support. So that would just be development tax on the tools, plus the ability to update them basically on demand. And if they ship in the box, you've got the rigor around making sure that they're completely bug free, because getting a fix out to them is also tough if they're in Windows. But then also adding features to them is really easy. We could talk today and you could say, "Hey, why don't you add this feature, or make this change, or fix this bug in tool X?" And I can literally have that published tomorrow or a few hours from now. Making a change to Windows itself is, as it should be, a far more time-consuming and complicated process.

Please read: Risky business: The tradeoff between security and convenience

We also aim to keep Windows as small as possible, minimize network bandwidth for the more than 1 billion Windows users, and maximize their free disk space. We only include things in Windows that we believe a large portion of Windows users will use. The Sysinternals tools are awesome, but they appeal to an audience of developers and tech enthusiasts, which is a tiny fraction of the user installed base.

Do you have any rules for the tools?

An important part of Sysinternals is the attributes that define a Sysinternals tool and have from the very start, which is a single file executable that leaves nothing or almost nothing behind on your system, as opposed to the traditional software that comes with an installer. You can run them off a file share. You can even run them directly from the Sysinternals site with the "Run now from Sysinternals Live" link on each tool page.

Do you still actively work on the tools?

Sysinternals was just me and Bryce up until a few years ago. And then I started to get contributors at Microsoft who said, '"Hey, I'd like to add this feature." So I would let them have access to the source and they'd add the feature. I've actually hired a person to manage Sysinternals engineering systems and also another developer for the tools. So two full-time people work on the tools and the engineering system. Engineering systems include the source control management systems, as well as the build pipelines for the tools. In the old days, Bryce and I would build the tools on our own desktops and our source control was me and him having copies of it.

Sysinternals is officially a Microsoft thing now?

Winternals and Sysinternals were both parts of the Microsoft acquisition in 2006.

Do you have any numbers on the tools' popularity?

There are about 15 million downloads of the tools a month, but that doesn't necessarily represent all of the spreading, because it's mirrored in different places and companies take one download and spread it through their organization. The most popular tools are Process Explorer, Autoruns, and Process Monitor. Sysmon has kind of taken over and become the de facto security monitoring tool for Windows. One of my favorite tools is ZoomIt ("a screen zoom and annotation tool for technical presentations that includes application demonstrations"), which I always used in presentations. And I wrote it for myself.

Microsoft has been putting tools into GitHub lately. Why aren't the Sysinternals tools in GitHub?

Sysinternals takes advantage of undocumented Windows implementation details such as APIs and data structures. In light of this, releasing code that uses undocumented APIs would be de facto documenting them and constrain the future evolution of Windows. However, the Linux version of Sysinternals relies entirely on public, stable Linux APIs and can safely be released as source code.

Please read: 3 good ways to run Linux on Windows

Any chance of making the other tools open source?

I might start going through and open sourcing the ones that are clean, as far as undocumented API.

How did they get from some tools you wrote to a site other people could go to?

Originally, I didn't have a website for them and a friend agreed to put them on his. I was happy with just having him be the distributor for them. But then after I'd come up with a new version or a bug fix and I'd say, "Hey, Andrew, can you post this?" it'd be a few days before he finally got around to do it. And I'm like, "OK, I just need to put this up myself." So that's where we finally created NTinternals.com. Oh, here's a little piece for your story. We called it NTinternals.com, and in 1997, I got a letter about a year or a year and a half after that from a Microsoft attorney saying use of NT is a violation of Microsoft's trademark. So that really pissed me off.

That's ironic.

So we changed the name to Sysinternals.com. So that's the reason that ... otherwise it might still be called NTinternals.

Anything coming in the future for Sysinternals?

We are planning on doing a 25th anniversary Sysinternals conference or summit in September. It will be a virtual event and advertised on the Sysinternals homepage.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.