If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
New symbol in Task Manger task list
This is minor in the extreme..but I just noticed something
I hadn't seen before. Next to some tasks listed by Task Manager is a little green symbol that looks like a leaf with a stem. At the moment I see four instances - all are "attached" to a Windows task, i.e., Cortana. Any idea what it means? |
Ads |
#2
|
|||
|
|||
New symbol in Task Manger task list
In article ,
Jason wrote: This is minor in the extreme..but I just noticed something I hadn't seen before. Next to some tasks listed by Task Manager is a little green symbol that looks like a leaf with a stem. At the moment I see four instances - all are "attached" to a Windows task, i.e., Cortana. Any idea what it means? suspended process, which saves energy, making it 'green'. |
#3
|
|||
|
|||
New symbol in Task Manger task list
In alt.comp.os.windows-10, on Sat, 8 Dec 2018 19:29:55 -0500, Jason
wrote: This is minor in the extreme..but I just noticed something I hadn't seen before. Next to some tasks listed by Task Manager is a little green symbol that looks like a leaf with a stem. At the moment I see four instances - all are "attached" to a Windows task, i.e., Cortana. Any idea what it means? Doessn't that mean one of the sub-tasks is suspended. Every time I 've seen that leaf, one of my subtasks was suspended, and said so right on the same subtask line. Right now that's true of my Cortana also. I don't especially remember it being Cortana the last time. |
#4
|
|||
|
|||
New symbol in Task Manger task list
On 12/08/2018 6:29 PM, Jason wrote:
This is minor in the extreme..but I just noticed something I hadn't seen before. Next to some tasks listed by Task Manager is a little green symbol that looks like a leaf with a stem. At the moment I see four instances - all are "attached" to a Windows task, i.e., Cortana. Any idea what it means? Mouseover it and it will tell you what it is. Rene |
#5
|
|||
|
|||
New symbol in Task Manger task list
|
#6
|
|||
|
|||
New symbol in Task Manger task list
On 09/12/2018 03:20, Jason wrote:
I did mouse over it and nothing happened.... I'm not surprised. Blind people can't see or read anything without special tools. Is this new since a recent update or has it always been around and I just missed it? It's new for you. -- With over 950 million devices now running Windows 10, customer satisfaction is higher than any previous version of windows. |
#7
|
|||
|
|||
New symbol in Task Manger task list
In alt.comp.os.windows-10, on Sat, 8 Dec 2018 22:20:42 -0500, Jason
wrote: In article , says... Mouseover it and it will tell you what it is. Rene Thanks to all who responded. I did mouse over it and nothing happened.... Me neither. Is this new since a recent update or has it always been around and I just missed it? Fairly new, I think. Is that because suspension is new, or only because indicating it is, or indicating it here is? |
#8
|
|||
|
|||
New symbol in Task Manger task list
Jason wrote:
rlamont SAID ... Mouseover it and it will tell you what it is. I did mouse over it and nothing happened.... Is this new since a recent update or has it always been around and I just missed it? Suspension of processes has been around since Windows Vista. Rather than terminate the process, it gets suspended. Resuming a suspended processes takes less time than reloading it. When memory is low, suspended processes can be quickly killed (they aren't running, after all, so they don't need to execute any unload instructions to exit) to load a new process. A suspended process consumes far less memory but leave the process nearly immediately available for reuse, so it has more value on computers that have less system RAM. A suspended process consumes no CPU cycles, so the CPU does less work which means less power gets consumed along with less heat generated. https://www.streetdirectory.com/trav...d_process.html https://www.addictivetips.com/window...mn-windows-10/ https://www.howto-connect.com/what-a...er-windows-10/ https://ntopcode.wordpress.com/2018/...ows-internals/ SysInternals' has had its PsSuspend tool for a long time. I don't remember when it showed up. The above procedure (for end users versus programmatically suspending a process) is clumsy, so PsSuspend is easier but it is a console-mode program (you need to run it in a command shell). https://docs.microsoft.com/en-us/sys...oads/pssuspend SysInternals' Process Explorer also adds the ability to suspend or restart processes; see: https://www.howtogeek.com/199976/how...cess-explorer/ PowerShell can also be used to suspend/restart processes. Task Manager in Windows 10 was enhanced to show which processes are suspended (or eligible). Many programs that load on startup do not remain running. They load themself and then immediately exit. Seems a waste of CPU cycles but they do that to add themself to the PreFetch cache for quicker (shorter) load times. |
#10
|
|||
|
|||
New symbol in Task Manger task list
|
#11
|
|||
|
|||
New symbol in Task Manger task list
Jason wrote:
In article , says... When memory is low, suspended processes can be quickly killed (they aren't running, after all, so they don't need to execute any unload instructions to exit) Don't they need to close open files? Sysinternals Handle or Sysinternals Process Explorer, record "handles", a way of tracking open files. The handles are tracked by "PID" or Process Identifier. If a Suspended (green twiddly) doesn't have a PID, then by observation, there can't be an open handle. It would have to close all the handles, before the "PID" goes away and the PID is harvested and returned to the PID pool. PIDs are recycled as time goes by. (There is a relatively small pool of PIDs on the system.) If the Suspended entry *does* have a PID, run Process Explorer and look for its Handle list. Note that Process Explorer gives the most comprehensive picture possible, when you elevate it to Administrator (you can look inside threads then). Best guess, Paul |
#12
|
|||
|
|||
New symbol in Task Manger task list
Paul wrote:
If a Suspended (green twiddly) doesn't have a PID, then by observation, there can't be an open handle. The suspended processes that I see SearchUI.exe (Cortana) ShellExperienceHost.exe LockApp.exe WindowsInternal.ComposeableShell.Experience.TextIn put.InputApp.exe all have PIDs and Procexp shows those processes have handles just like "normal" processes. |
#13
|
|||
|
|||
New symbol in Task Manger task list
Andy Burns wrote:
Paul wrote: If a Suspended (green twiddly) doesn't have a PID, then by observation, there can't be an open handle. The suspended processes that I see SearchUI.exe (Cortana) ShellExperienceHost.exe LockApp.exe WindowsInternal.ComposeableShell.Experience.TextIn put.InputApp.exe all have PIDs and Procexp shows those processes have handles just like "normal" processes. So it's hardly ready for harvesting then. It would have to be unsuspended, then killed. Paul |
#14
|
|||
|
|||
New symbol in Task Manger task list
Paul wrote:
Jason wrote: In article , says... When memory is low, suspended processes can be quickly killed (they aren't running, after all, so they don't need to execute any unload instructions to exit) Don't they need to close open files? Sysinternals Handle or Sysinternals Process Explorer, record "handles", a way of tracking open files. The handles are tracked by "PID" or Process Identifier. If a Suspended (green twiddly) doesn't have a PID, then by observation, there can't be an open handle. It would have to close all the handles, before the "PID" goes away and the PID is harvested and returned to the PID pool. PIDs are recycled as time goes by. (There is a relatively small pool of PIDs on the system.) If the Suspended entry *does* have a PID, run Process Explorer and look for its Handle list. Note that Process Explorer gives the most comprehensive picture possible, when you elevate it to Administrator (you can look inside threads then). Best guess, Paul Maximum /value/ for a PID (pid_max = DWORD_MAX): 32-bit: 65532, or 0xFFFC 64-bit: 4294967292, or 0xFFFFFFFC GetProcessID() returns PID as a DWORD. That means all PIDs happen to be divisible by 4 (PID = 0 being a special case for the System Idle Process, although mathematically zero is divisible by anything). That's for NT kernels. Back in 9x/DOS, PIDs were not always divisible by 4. The bottom 2 bits of a PID's DWORD value are zero hence why they are a multiple of 4. Instead of FFFF FFFF for a PID's max value, it is FFFF FFFC. FFFF FFFC divided by 4 is 3FF FFFF, or 1073741823 (decimal), for the max number of PIDs. 1,073,741,823 is a hell of a lots of processes to be running concurrently. I think the smallest memory allocation is a 4096-byte (0x1000) which is a page in memory. With 1,073,741,823 PIDs available at 4096 bytes minimum for each, that's FFFF FFFC * F, or FFF FFFF C000, or 17,592,186,028,032 bytes of system RAM that the maximum number of PIDs, if all consumed, would minimally consume. Other than a data table loaded into memory, or someone writing their program in assembly, 4096 bytes is pretty small for any program. Unless suspended, each context switch for each PID to get some CPU cycles would kill the OS long before the maximum count of PIDs was reached. https://msdn.microsoft.com/en-us/library/ms810603.aspx "This does not mean that the smallest amount of memory that can be allocated in a heap is 4096 bytes; ..." It gets complicated and my above math was simplistic. malloc() specifies the requested memory size in bytes, not pages. It's been too long since I've done that level of programming. Although memory allocation size might be less than a page, aren't the allocations on page boundaries (i.e., page aligned)? https://en.wikipedia.org/wiki/C_dyna...ion#Heap-based "The granularity of this depends on page size." In any case, "There is a relatively small pool of PIDs on the system" seems inaccurate unless you meant the existing PID count and not the total count of PIDs that could be available. |
#15
|
|||
|
|||
New symbol in Task Manger task list
VanguardLH wrote:
Paul wrote: Jason wrote: In article , says... When memory is low, suspended processes can be quickly killed (they aren't running, after all, so they don't need to execute any unload instructions to exit) Don't they need to close open files? Sysinternals Handle or Sysinternals Process Explorer, record "handles", a way of tracking open files. The handles are tracked by "PID" or Process Identifier. If a Suspended (green twiddly) doesn't have a PID, then by observation, there can't be an open handle. It would have to close all the handles, before the "PID" goes away and the PID is harvested and returned to the PID pool. PIDs are recycled as time goes by. (There is a relatively small pool of PIDs on the system.) If the Suspended entry *does* have a PID, run Process Explorer and look for its Handle list. Note that Process Explorer gives the most comprehensive picture possible, when you elevate it to Administrator (you can look inside threads then). Best guess, Paul Maximum /value/ for a PID (pid_max = DWORD_MAX): 32-bit: 65532, or 0xFFFC 64-bit: 4294967292, or 0xFFFFFFFC GetProcessID() returns PID as a DWORD. That means all PIDs happen to be divisible by 4 (PID = 0 being a special case for the System Idle Process, although mathematically zero is divisible by anything). That's for NT kernels. Back in 9x/DOS, PIDs were not always divisible by 4. The bottom 2 bits of a PID's DWORD value are zero hence why they are a multiple of 4. Instead of FFFF FFFF for a PID's max value, it is FFFF FFFC. FFFF FFFC divided by 4 is 3FF FFFF, or 1073741823 (decimal), for the max number of PIDs. 1,073,741,823 is a hell of a lots of processes to be running concurrently. I think the smallest memory allocation is a 4096-byte (0x1000) which is a page in memory. With 1,073,741,823 PIDs available at 4096 bytes minimum for each, that's FFFF FFFC * F, or FFF FFFF C000, or 17,592,186,028,032 bytes of system RAM that the maximum number of PIDs, if all consumed, would minimally consume. Other than a data table loaded into memory, or someone writing their program in assembly, 4096 bytes is pretty small for any program. Unless suspended, each context switch for each PID to get some CPU cycles would kill the OS long before the maximum count of PIDs was reached. https://msdn.microsoft.com/en-us/library/ms810603.aspx "This does not mean that the smallest amount of memory that can be allocated in a heap is 4096 bytes; ..." It gets complicated and my above math was simplistic. malloc() specifies the requested memory size in bytes, not pages. It's been too long since I've done that level of programming. Although memory allocation size might be less than a page, aren't the allocations on page boundaries (i.e., page aligned)? https://en.wikipedia.org/wiki/C_dyna...ion#Heap-based "The granularity of this depends on page size." In any case, "There is a relatively small pool of PIDs on the system" seems inaccurate unless you meant the existing PID count and not the total count of PIDs that could be available. Well, I finally got it to go over 65536, and you're right. https://i.postimg.cc/MK9VWZG8/PID-gt-65536.gif It took a few tries to get it up there. And I only regained control of the machine by accident. Paul |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|