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?

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'.

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.

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

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....

Is this new since a recent update or has it always been
around and I just missed it?

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.

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?

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.

In article , says...

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.

Thanks for that! Bookmarked.

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?

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

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.

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

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.

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