Why does holding the Ctrl key when selecting New Task from Task Manager open a command prompt?

Commenter Adam S wonders why holding the Ctrl key when selecting New Task from Task Manager will open a command prompt.

It's a rogue feature.

Windows XP introduced visual styles, and one of the tricky parts of debugging visual styles is that if the visual style engine goes berzerk, you can't see anything! One of the problems that the visual styles folks encountered when developing their feature was that sometimes they would get into a state where the Run dialog would stop working. And without a Run dialog, you couldn't install or launch a debugger to begin investigating what went wrong.

The solution: Add the rogue feature where holding the Ctrl key when selecting New Task from Task Manager opened a command prompt directly, without involving the Run dialog. From that command prompt, you can then install the debugger and start debugging. (This technique also took advantage of the fact that console windows were not themed in Windows XP. If the visual style system got all messed up, at least your console windows worked!)

Over time, the bugs in the visual style system got worked out, and this rogue escape hatch was no longer needed, but for whatever reason, it never got removed.

Comments (16)
  1. Anonymous says:

    Virtualization has its place, but it also introduces a whole host of bugs into the environment.  You don't want your OS to depend on a quirk of the virtualization environment, or become dependent on the VM's driver set.

    In any case, this anecdote is talking about XP.  VMWare was just getting started, and x86 virtualization was software-only.

  2. Anonymous says:

    if visual styles crashes how are you accessing the task manager?

  3. Anonymous says:

    @pcooper: Excellent question. I can't wait to read the answer sometime in late 2014. ;)

  4. SimonRev says:


    My guess would be that during development, the Task Manager didn't use visual styles.

  5. Anonymous says:

    @pcooper: it's called dogfooding, or eating your own dog food.  Windows devs run dev Windows to add pressure to fix critical issues, major annoyances, and generally ensure it runs on a decent mix of hardware before it gets out to the wider parts of the testing process.

    See also: blogs.msdn.com/…/10071954.aspx

  6. Anonymous says:


    Ctrl-Shift-Esc, Alt-F, Ctrl-Enter.

  7. Anonymous says:

    @pcooper: In the Windows XP days, kernel debugging still happened remotely over a null modem cable attached to the serial port, as described at support.microsoft.com/…/151981

  8. Anonymous says:

    I had forgotten how long ago XP was when I asked, I guess. And I do understand that you'd want a bunch of installs on "real" computers, for QA and dogfooding purposes. The story just sounded to me like it was the normal approach to how the "styles" engine was developed, so it sounded a little odd, but considering when it was, I suppose that it probably did make sense at the time. Perhaps a better question is this: How have the improvements in virtualization over the last few years changed how Windows gets developed?

  9. Anonymous says:

    And since people make their own themes, it kind of needs to stay.

  10. For most components you can just build the binary (.dll/.exe/.sys) or perhaps a small handful of binaries, and then apply those to a recent full build of Windows.

    You may need to get around things like boot-required-file signature enforcement, depending on exactly what the component is.

  11. Anonymous says:

    Okay, this rogue feature found its way to the brand new Windows8's TM.exe. Excellent.

  12. Anonymous says:

    I find it interesting how much of your debugging/development for Windows seems to happen on the actual system. I guess I would have expected most development to happen in some kind of VM environment, that you could somehow attach your debugger on your dev system to. Is the process generally something like "write code, build a Windows install, put it onto a computer, and see how it works"? What *is* your day-to-day development like (at least the parts of it that you're allowed to share)?

  13. I was wondering if it was going to be in Win 8's task manager.  I was about to connect to my Server 8 VM when PastorGL answered my question for me.

    Of course, I probably won't get out of the reflex actions of Win+R, cmd, Enter.  That doesn't work well when I'm on boxes where admins practice "security through obscurity" and make me do dumb things like make a shortcut to cmd.exe on my desktop so I can run a command shell – taskmgr is disabled, Win+R is disabled but you can always make a shortcut :)

    Same goes for those admins who like to disable access to C: – again a shortcut does the trick.

    ACLs people!!!  (and whitelisting of apps if you want to go really nitpicky)

  14. Anonymous says:

    @Tom: VMWare was available when XP came out. I believe it only required Windows NT at the time! I do remember trying to run it on my NT 4 system, with it complaining it needed 128MB of RAM. My old desktop was built with 256MB and I ran Linux on it under Windows 2000 with VMWare.

    Of course, when visual theming and such was being developed, it's likely the same reason why they didn't send the space shuttle to save Apollo 13.

  15. Anonymous says:

    First I thought "gui isn't kernel", but then I remember, in windows xp, it was.

  16. Anonymous says:

    GUI isn't Kernel. It is in Kernel mode on top of Kernel itself and Graphics driver (page ~51 of Windows internals 5th ed). Big difference.

Comments are closed.