Why does Task Manager tell me that I have a Startup program named Program?
Raymond Chen
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.
Light
Dark
16 comments
Looks like someone needs to file a bug report with Dave Plummer. 🙂
You should do a collaboration with him sometime and appear on his channel.
Dave left in 2003, the Startup tab was added in the Windows 8 UI rewrite.
Try filing a report in Feedback Hub …se how well that goes.
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.
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.
You can see the command line in Task Manager as well; you just need to add it as a column.
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”.
The data is there. Just query for all the modules in the process. You can then decide which of them is the “main” one for the program. It’s probably one of the ones whose name ends with .exe. Except with rundll32.exe. or regsrv. or explorer.exe, except when it is.
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.
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.
This is because the OS does not make a distinction between a name that is useful for the computer and a name that is useful for the user. The name shown to the user should have no limitations at all, it could even contain a colon, a CR/FL if this is useful for the user, while the name used by the computer should be useable on command-line terminals that simply concatenate strings to make filenames.
And since command-line terminals use the space to delimit arguments, it’s heresy to allow spaces inside file names.
Basically, each file would have a constrained name that identifies it for the OS and a completely free title that is shown to the user.
Since having such a beast would be even more confusing that limiting the character set, we should stick with the limitation.
Why even have file names? Just give each file a guid and a display title!
We already have 64/128 bit file IDs and on NTFS you also have GUIDs: https://devblogs.microsoft.com/oldnewthing/20110228-00/?p=11363
Actually each file already has such constrained name since the first version of Windows, it’s called 8.3/short name (unless the user has disabled 8.3 name creation for the volume or globally). You can use “dir /x” command to list them and use them anywhere in place of normal file name. Sometimes I had to resort to short names either due to incorrect space character handling or MAX_PATH limitation of certain programs. Although few programs might work quirky with short names as well.
Fun to lookback into 2005 on the subject of createprocess and see where we now are with electric cars 🙂
Such a pity the old comments are gone. There were real masterpieces there.