Why does Task Manager tell me that I have a Startup program named Program?

Raymond Chen

Raymond

If you go to Task Manager’s Startup tab, it lists the programs that are registered in the Startup group or the Run key to run automatically when you sign in. But you might see an entry called simply Program, with a blank icon and no publisher. What is this thing?

This thing is a program that registered itself incorrectly.

Command lines consist of a program name, a space, and the program arguments. If the program name contains spaces, then it needs to be enclosed in quotation marks. Otherwise, the first space is considered to be the end of the program name. What you’re seeing is a program that resides somewhere in the C:\Program Files or C:\Program Files (x86) directory, but they forgot to quote their program name. As a result, the space after Program is considered to be the end of the program name, which is why it shows up as just Program in Task Manager.

The program does manage to run because the CreateProcess function does autocorrection, but Task Manager doesn’t do the same autocorrection, so it thinks that the Startup program is C:\Program.exe.

8 comments

Leave a comment

  • Avatar
    cheong00

    Given the amount of memory we generally have now, would Microsoft consider placing the full path of the executable it runs somewhere in the process’s metadata so the task manager can reference correctly?

    Other kind of nice-to-have is “the list of process ids” of “chain of parent process”. It would be helpful to “kill child process tree” on the case where some process in the middle of the tree had already terminated. And it may make the process tree of process explorer look better when some applications spawn new process with CMD.EXE that immediately closed after the real command it was used to run has been started.

    • Avatar
      Antonio Rodríguez

      The items in the Startup tab aren’t processes. They are just a collection of entries in different parts of the system (the registry, the start menu, perhaps the group policy) where programs can hook to be launched at startup. But that does not warrant they are running at the time you open the Task Manager. For example, an update agent or a backup tool can run at session start, and terminate when it’s done. Furthermore, if the process is still running, all Task Manager has is the command run on startup. If there are several processes with the same executable, you can’t say which on was create at startup. And even if there is just one, you can not say for sure it’s the right one.

      Also, Windows *does* relate each process with its parent, and Task Manager has a command to kill the entire branch of the process tree. Just go to the Details tab and right click on any process 🙂 . It’s there from the first version of NT back in 1993, because, among other things, it was needed for Posix compliance, very important so it could replace Xenix in corporate/governmental markets.

      That said, I agree. Process Explorer lets you see the process’ command line, but AFAIK it uses “indirect” means to do that because Windows does not provide an official way to retrieve it. The documentation warns you that it’s possible for a perfectly fine process not to have a command line because of that. Having that information available can be very helpful when troubleshooting, so yes, I agree that Windows should store and provide it.

      • Avatar
        cheong00

        Oh. Since I see the “Open File Location” context menu item is only enabled when that startup item is enabled, I thought the ability to retrieve path for binary is related to “the item is enabled” and run before.

        And when I was talking about the parents list, I’m not only talking about the parent process, but the” parent of parent and so on” down to maybe the shell or event winlogin.exe, so if any of the parent processes in the list got terminated, I can still search up the “parents list”.

  • Avatar
    M. W.

    Backwards-compatibility is a blessing and a curse. Obviously, staring over from scratch isn’t feasible for many reasons, but at the same time, it means working within the limits of ancient design. 😕 Filename handling is probably the biggest backwards-comparability bugaboo in Windows. I really hate that we can’t use question-marks in filenames. 🤦

    I wish that either someone with a time-machine could go back and make them use a different character for that wildcard or at least there were some way to swap the character now, even if it means making the files less portable between systems without the setting—it wouldn’t be the only setting that is frustrating to not have on other systems, but it would be more worth it than other settings.

    • Gunnar Dalsnes
      Gunnar Dalsnes

      This is an artificial limitation in win32 (to allow lazy programming). NTFS support ? in filenames. These artificial limitation could be removed but could possibly confuse some programs, but it would be totally worth it. In Linux, all but / and \ is allowed and I think same apply to NTFS.