Mark's Sysinternals Blog

A Windows service provides functionality to the operating system and user accounts regardless of whether anyone is logged into a system. Windows XP comes with around four dozen services enabled by default, including ones that many people consider superfluous like Remote Registry, Alerter, and SSDP Discovery (Universal Plug and Play). A question many Windows administrators commonly have is therefore, which services can I safely disable? What if I told you that for at least basic functionality like Web surfing and application execution, Windows doesn’t need any services? In fact, you can also do those things without system processes like Winlogon.exe, the interactive logon manager, and Lsass, the local security authority subsystem.

The following steps, which you must follow carefully to achieve a minimal Windows system, were derived by Dave Solomon through experimentation, and when he discovered that Windows was usable without all the core system processes we were dumbfounded. After figuring this out he and I polled senior Windows experts like the vice president of the Core Operating Systems Division, the technical lead of the Virtual PC team, and a lead Windows security architect to see if they thought that Windows would function at all, much less if Internet Explorer would work, without the support of Winlogon, Lsass, and services, and the unanimous answer was ‘no’. Even after we showed them the demonstration I’m about to share with you they all thought that we’d staged some kind of trick.

The first step to achieving a minimal Windows configration is to kill the system processes I’ve mentioned. You can’t use Task Manager for the job, however, because it has an internal list of processes that it considers critical and that it won’t terminate. Try to kill Smss.exe, Winlogon.exe, Services.exe, Lsass.exe or Csrss.exe and you’ll see this dialog:



So if you don’t have it already download Process Explorer. To make things go more quickly uncheck the Confirm Kill entry in the Process Explorer Options menu. Then kill Smss.exe, the Session Manager process. The reason we start with Smss.exe is that Smss.exe watches the back of Winlogon, the process it creates during the boot, so if you terminate Winlogon first Smss.exe gets upset and blue screens the machine with an error indicating that the Windows logon process terminated unexpectedly. And if you kill Lsass or Services without killing Winlogon you'll see this dialog that Winlogon shows before it shuts down the system (you can abort the shutdown by running "shutdown -a"):



Once Smss.exe is out of the way select Winlogon and choose Kill Process Tree from in the Process menu. This terminates Winlogon.exe, Lsass.exe, Services.exe, and all the Windows service processes. We’re almost done.

The next step is to kill all other standard processes except for Csrss.exe (and of course Process Explorer). Csrss.exe is the only process in the system that has the “critical process” bit set in its kernel process structure (EPROCESS) flags field. On the termination of a process with the flag set the kernel halts with a CRITICAL_PROCESS_DIED blue screen. Note that you won’t be able to terminate the System Idle Process, System, Interrupts, or DPC processes. The Idle process isn’t a real process and simply tracks the time when no thread is executing. The System process holds operating system kernel threads and device driver threads, and Interrupts and DPCs are artificial processes that Process Explorer uses to display interrupt and Deferred Procedure Call (DPC) activity.

Because Process Explorer shows the Interrupts and DPCs artifical processes switch to Task Manager at this point to get a real idea of what’s actually running by activating the Run command in Process Explorer’s File menu and entering “taskmgr”. Then exit Process Explorer and look to Task Manager’s Process tab. This is what you should see (themes disappear when the Svchost.exe process hosting the theming service terminates):



You have achieved minimal Windows: the only two processes, not including Task Manager, are System and Csrss.exe. You’re now ready to start experimenting. Verify that you can surf the Internet by launching “iexplore” from Task Manager’s Run command in its File menu. Then restart Explorer by running “explorer”. You’re done with Task Manager so you can exit it.

There will be a delay before Explorer redraws the desktop because it waits for the Service Control Manager (SCM) to signal the ScmCreatedEvent, which Services signals during its initialization. Below is the stack of the main Explorer thread waiting. The second parameter to WaitForSingleObject is a timeout value that’s interpreted as milliseconds and 0xEA60 is 60,000 – 60 seconds:



Once Explorer starts it clips the task bar off the bottom of the display so get it back by right-clicking on the barely visible task bar and applying the ‘Show Quick Launch” option. Notice that even though the task bar is fully visible it doesn’t show the active windows.

With Explorer, the start menu and desktop back you can wander your system, trying various applications and utilities to see how they respond when there are no services running. There are many things that will work, but of course also many things that won’t. For example, here’s the Services node of the Computer Management MMC snapin displaying an expected error message:



What are the real limitations of running like this? Some will become obvious during your exploration, but a major one is that you won’t be able to logoff (or shutdown) since neither Lsass nor Winlogon are running. Networking is also crippled, especially in a LAN, since accessing other computers requires the participation of Lsass in the cross-machine domain authentication process.

The bottom line is that this stripped-down Windows configuration is not practical, but makes a cool demonstration of just how little of Windows is required for basic functionality.

On a more personal note, I’m going to be in the Cape Canaveral area on Thursday, August 11, and so am calling out to any NASA employee Sysinternals fans to see if you’d be willing to arrange for a special tour of the space center.

A few months ago I began experiencing periodic system freezes of about a second where even my mouse would pause during a movement. Needless to say, this became very annoying very quickly. A few minutes with Process Explorer, however, and I not only determined the cause, but came up with a fix.

One apparent clue as to the cause of the hangs was that I only experienced the freezes when I had the beta release of VMWare 5 running. That fact alone wasn’t enough to blame VMware for the spikes and in any case my reliance on VMware prevented a workaround of simply not using it. I therefore wanted to determine if VMware was really the cause and so the first step of my investigation was to look at the system’s overall CPU history in Process Explorer’s System Information dialog. I clicked on the mini-CPU history chart in the Process Explorer toolbar and in the larger graph confirmed a CPU spike every 10 seconds. I moved the mouse over a spike and the graph’s tooltip reported the System process as the major contributor to CPU usage at the time of the spike:



The System process serves as the host process to operating system worker threads, such as the modified and mapped page writer threads, as well as dedicated device driver threads, so my investigation wasn’t complete: I needed to look inside the System process to see what thread or threads were responsible for the spikes. To do that I double-clicked on the System process to open its Process Properties dialog and selected the threads tab. I pressed the space bar to pause Process Explorer’s refresh updates and at the next CPU spike (it might have take a two or three tries to get the timing right) I pressed F5 to cause a manual refresh:



Two threads contributed the majority of CPU usage. One had a start address in Http.sys and the other in Ftser2k.sys. Http.sys was introduced in Windows XP to serve as an in-kernel Web server accelerator that can serve cached content directly from kernel-mode. I didn’t know what Ftser2k.sys was so I clicked on the Module button to view the file properties for the driver’s file and saw that it describes itself as the “FTDIBUS Serial Device Driver”. This wasn’t very helpful so I investigated some more and found that it’s a driver that provides a virtual serial port interface for USB devices so that applications that aren’t USB-aware can interact with USB devices. I had recently installed XM Satellite Radio’s XM PC Player (which XM has since discontinued) and suspected that it was the application that required the Ftserv2k driver. Closing the XM Player resulted in Ftser2k’s CPU usage dropping to 0, confirming that it was the application using the driver’s services. However, I continued to experience CPU spikes in Http.sys.

My attention therefore turned to Http.sys. Since Http.sys simply implements a cache I theorized that IIS, which I run on my Windows XP system to host the Sysinternals staging site, would function even when Http.sys wasn’t present. I opened a command-prompt and typed “Net stop http” to stop the driver and was informed that several dependent services would also stop if I stopped the driver, but answered affirmatively anway:



Within a few seconds I verified that that stopping the driver ended the CPU spikes. I spent a few more minutes testing IIS and VMware to make sure that the driver’s absence had no adverse effect and came to the conclusion that the system was functioning fine without it. My next step was therefore to disable the driver permanently. I opened the Device Manager, selected “Show Hidden Devices” in the View menu, navigated to HTTP in the “Non-Plug and Play Drivers” node and double-clicked to open its properties dialog. On the Driver tab I changed its startup type from “Demand” to “Disabled”, which would prevent the driver from starting the next time the system booted (note that I could have just as easily navigated in Regedit to HKLM\System\CurrentControlSet\Services\Http and changed the Start value from 3 to 4).

My CPU spiking mystery was solved. I might have spent time trying to determine why Http.sys was causing the spikes in the first place, but since they only occurred when the beta of VMware 5 was running it obviously had something to do with VMware’s networking subsystem. Since I wasn’t using any applications that required Http’s services I turned my attention back to the work I had interrupted with the investigation. I recently re-enabled Http.sys with the final release of VMware 5 running and the spikes no longer occur.

So why do I use VMware instead of Virtual PC, even for my presentations at Microsoft and Microsoft conferences like TechEd? I can answer with one word: snapshots. Snapshots are a VMware feature that allows you to save the state of a VM, make modifications to the VM and later return its state to that of the snapshot. I create a baseline “clean” operating system installation snapshot and perform experiments, including installing software, and can always restart with the clean installation.

VMware 5 takes snapshots a step further by introducing snapshot “trees”. Using snapshot trees I can start with my clean OS snapshot, get the VM into a state that demonstrates an interesting behavior, and then create another snapshot. I make more modifications and snapshot again, or go back to the original clean snapshot and take the VM in a different direction to make another branch of the snapshot tree.

In my malware talk, for example, I use two snapshots to demonstrate how RootkitRevealer can detect the HackerDefender rootkit. I start with the clean OS snapshot, copy HackerDefender to the system, open an Explorer window to the files and create a new snapshot. Then I activate HackerDefender and run RootkitRevealer through its scan where it reports the presence of the cloaked HackerDefender files and Registry keys. Then I snapshot again. During the presentation I resume the first snapshot and show how HackerDefender’s files disappear when I activate the HackerDefender executable. A little later I resume the second snapshot and display RootkitRevealer’s ability to detect the cloaked files, but without making the audience wait through a scan, something which takes several minutes.

I’ve grown so dependent on snapshots that only when Virtual PC includes snapshot trees will I consider switching.