When Administrator is just not enough

June 20, 2012 - Programming

First, a warning:

WARNING:Running programs under the LocalSystem account is dangerous! Only run programs that are built into the OS, and programs you trust. NEVER run a Browser under this account, or any similarly designed program. This should ONLY be used for trouble-shooting or cleaning up messes things like the Windows Update service leave behind!

Now that that is out of the way…

One of the nice things about later versions of windows is that you don’t automatically have full control over everything. Some people try to say this is bad, because it is their computer so they should be able to do what they want, but the point they are missing is that the changes to the default security settings is not to prevent them from doing things, but to prevent nasty programs from being able to do anything they want. By definition the settings for a user control more what the programs running under that account can do; and only serve to restrict the user themselves by virtue of them not really being able to do anything that a program cannot do. (If no program can delete a file, that user cannot delete it either).

Sometimes, however, this can get in the way. Stubborn files, for example, might refuse to be deleted. Usually, running a program as administrator clears this up, but sometimes even this doesn’t work.

In particular, a failed Windows update, or an update that doesn’t clean up properly, can leave a mess of files around. Usually these are weirdly named folders in the root of the system drive. A quick search for words like that via google reveals that this is not an uncommon problem. The problem is that nothing can delete these files- you cannot run as an administrator to delete them, tools like unlocker and deleter don’t work either. The cause is that the files weren’t even created by the administrator, but rather by the LocalSystem account under which Windows update runs. (this is required so that the update can update dll files and other files that are in-use, which usually will require a reboot for a myriad of reasons that I won’t get into). The files are supposed to be deleted afterwards- they are simply temporary files- but a unexpected power loss or an error could prevent proper cleanup of these files. But since they are owned by LocalSystem, nobody else can delete them.

So the question is- how the heck do we clean-up the files?

well, if the only way to delete them is to become LocalSystem- let’s try that. After some experimenting, one of the most reliable ways I found was to create a service. You can do this by starting a Elevated Command Prompt, and entering the following command:

This creates a new service called runcmd. the /K start is necessary because the service control manager expects services you run to be… well, services. cmd is not a service, so it won’t register itself with the SCM and this SCM will kill the process after a timeout. using /K start, we can force that first spawned cmd to instantly start another one, since killing the parent process does not kill child processes, that cmd remains alive.

Running it is simple. just enter this command:

On my System, this didn’t seem to do anything, but a few moments later I received a “Interactive Services” notification:

So, CMD was running. I switched to the Interactive desktop, and was greeted (after this weird switch thing) with this:

The Interactive Services desktop.

Success! cmd was running under the LocalSystem account. This is good way to clean up files left about by services. However, while I was able to get explorer running (start menu), I wasn’t able to get explorer running (file manager). So I cheated, opened notepad, and used it’s file dialog. This method could be used to delete odorious files that refuse to be deleted on other ways.

Obviously, this should only be used when needed and the applications you run should be kept to a minimum, and you surely shouldn’t run browsers this way!

Have something to say about this post? Comment!