I'm starting to forget this one already, but, recently, I dealt with a virus that hacks the shell and inserts a handler for .EXE file.

You know how, when you double click on .DOC files or .XLS files, the system automatically opens it with the correct application? The way that works is that Windows Explorer has a mapping that describes how to start a .DOC or .XLS file with Word or Excel.

The normal thing for .EXE files is, basically, to do nothing. Just run it as-is.

A virus might alter this, so that, instead of running the EXE file, it runs another program first. (Then, that program will run the EXE file as normal, so that you don't notice something's wrong.) The particular instance I had popped up a window telling me I had a virus, and clicking on their button would sell me a product to remove it.

At least these intruders were somewhat honest.

After finding this problem with RegEdit, I edited out the issue. However, I also made a serious error, and effectively disabled my ability to execute any EXE file.

Getting out of this situation was difficult. What I ended up doing was figuring out a way to execute a file without passing it through the shell.

The solution was to use the Scheduled Tasks to run a .BAT file. That .BAT file contained a line that started RegEdit. I think this task was scheduled to run as Administrator so it would be able to save the registry (but I may be wrong on that part).

The point here is that Scheduled Tasks don't run through the shell. They run in the old Command Line Interface (CLI).

I guess the big question is - why can't I just run the CLI? Well, the CLI is also an EXE file - it's cmd.exe. So when you try to run that through the shell, it ends up being intercepted.