Some icons occasionally not in tray

[Terry Pinnell]

Now and again, even directly after booting XP, a few of my system tray
icons are not displayed in the tray. A regular example is a backup program
called Second Copy. The program is running, as shown in Task Manager, but
I cannot access it without the icon. All I can do at present is stop the
process from TM and restart the program.

Anyone know what might cause this please, and how I might fix it?

 

[Tim Meddick]

You will, undoubtedly, not be surprised to hear, that this is yet another
example of the myriad 'quirks' that plague the Windows XP os. No, there's
nothing you can do about it, as I, along with many others, have also found,
as we have long-searched for an answer to this phenomena. Other, that is,
than, as you quite rightly point out, to terminate (where possible) and
re-start the process.

Oh, and perhaps, in some cases, to open that program or feature's
properties or settings, and 'uncheck' the box marked "Always display icon
in system tray " (or some such) - apply - and then 're-checking' the box
again - and apply again.

This has worked for the Networking "Lights" icon (the "two blue TV screens"
icon, that each light-up in turn) in the past, I like to keep it there to
see basic networking activity.

==

Cheers, Tim Meddick, Peckham, London.

 

[SC Tom]

Now and again, even directly after booting XP, a few of my system tray
icons are not displayed in the tray. A regular example is a backup program
called Second Copy. The program is running, as shown in Task Manager, but
I cannot access it without the icon. All I can do at present is stop the
process from TM and restart the program.

Anyone know what might cause this please, and how I might fix it?

I had that problem with WinXP and still with Win7 for some programs. I used
Startup Delayer to take care of it:

http://www.r2.com.au/page/products/show/startdelay

On my old laptop, both Bluetooth (USB adaptor, not built in) and CoreTemp
would throw errors and not start, or if they did, no icon in the
notification area. By using Startup Delayer, I was able to delay BT by 11
seconds and CoreTemp by 9 seconds, and they would then start correctly and
show icons. Adds a few seconds to your boot time, but it's still quicker
than closing the program in Task Manager, and then restarting it.

 

[VanguardLH]

Now and again, even directly after booting XP, a few of my system tray
icons are not displayed in the tray. A regular example is a backup program
called Second Copy. The program is running, as shown in Task Manager, but
I cannot access it without the icon. All I can do at present is stop the
process from TM and restart the program.

Anyone know what might cause this please, and how I might fix it?

Too many programs don't realize that THEY are required to refresh the
state of their tray icon. These programs do not check for events that
requires a refresh of a tray icon, like changing the desktop theme,
color scheme, screen resolution, when the Windows taskbar changes from
hidden to visible. Restarting the program is how you force them to do a
refresh. Another method is to logout and login (which has Windows query
the list rather than have the program refresh its own icon). Under
Windows XP, the *programs* are expected to manage their own tray icons.
Many do so very poorly.

Despite that we users have come to call that portion of the Windows
taskbar the "tray area" or "system tray", its real name is the "system
notification area". Notification means just that: it is an area where
the *program* is expected to provide its own notification mechanism.
Any program that relies solely on the availability of a tray icon to
access functions within that program is poorly coded. It is, again, a
*notification* area. The same functions provided by a tray icon should
be the same functions provided by a config GUI that loads in its own
window. That is, a program should NOT rely merely on a tray icon to
provide access to its functions but should always provide a config
dialog for those same functions. Not providing a separate config UI
shows the programmers were lazy or ignorant. Many such programmers
utilize a library or function that someone else wrote so those
programmers really haven't a clue on how the system notification area is
to be used.

Notifications and the Notification Area
http://msdn.microsoft.com/en-us/library/windows/desktop/ee330740(v=vs.85).aspx
and
http://stackoverflow.com/questions/...explorer-to-make-it-refresh-the-systray-icons

Windows doesn't put the tray icon there. The app does that. If the app
doesn't well manage its tray icon then you have problems, like icons
that go missing, icons that remain after you supposedly exited the
program, icons that go dead, programs that display the icon after some
initialization has completed but it fails so their icon code is never
reached, killing a process so it cannot get to its code to remove the
tray icon, Explorer crashes, reloads, and the tray icons are missing not
because Explorer is supposed to put them there but because the programs
don't check the state of their own tray icons to put them back, and so
on. Simply adding a tray icon and never again refreshing its state
evidences a lazy programmer.

 

[Terry Pinnell]

Now and again, even directly after booting XP, a few of my system tray
icons are not displayed in the tray. A regular example is a backup program
called Second Copy. The program is running, as shown in Task Manager, but
I cannot access it without the icon. All I can do at present is stop the
process from TM and restart the program.

Anyone know what might cause this please, and how I might fix it?

I've now found this very interesting page and studying it:
http://winhlp.com/node/16?page=1&cs=2576&cl=1#comment-2155

 

[VanguardLH]

JAWS, the screen-access (via speech and/or Braille) for the blind
system, has a means to access what's in the tray; when this means is
being accessed, a sighted person can see that there is popped-up a text
list of the icons, along with ways to access them (such as left or right
click).

I presume the other access softwares (Window-Eyes, NVDA?, etc.) have
something similar.

It might be interesting to know how this list is generated - in other
words, whether it just uses the icons that are visible in the tray (in
which case it'd be susceptible to the same problems of inadequate
refresh etc.), or whether it uses a different means to see what _should_
be there. If the latter, it might help (to know what that means is).

My guess (without using the software to monitor its registry accesses
via SysInternals' RegMon or ProcMon) is that they read the following
registry entry:

Key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TrayNotify
Data item: IconStreams

I don't know what is the structure for this string but looking at it
shows some text that describes icons for the programs that I see in the
system tray.

 

[Terry Pinnell]

My guess (without using the software to monitor its registry accesses
via SysInternals' RegMon or ProcMon) is that they read the following
registry entry:

Key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TrayNotify
Data item: IconStreams

I don't know what is the structure for this string but looking at it
shows some text that describes icons for the programs that I see in the
system tray.

Thanks all, very helpful. At the next reoccurrence I'm going to try some
of those suggestions and those at that site I mentioned.

 

[Tim Meddick]

No, the reg key / value that you mention [IconStream] is responsible for
maintaining and reproducing the list found in :

TaskBar Control Panel > Hide Inactive Icons >
Customize

....shows a list of both "Current Icons" and "Past Icons" together with
check-boxes to enable / disable said icons from being shown by default
(when the "Hide Inactive Icons" feature is invoked), and it's these lists
of icons that are defined by the key / values :

[HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TrayNotify]

...."IconStreams" and " PastIconStreams" respectively, and has nothing at
all to do with actually holding icons in the actual Taskbar Notification
Area itself, just the lists in the Taskbar's "Customize Notifications"
control.

("Customize Notifications" Screenshot)
http://twitpic.com/azkzn9

==

Cheers, Tim Meddick, Peckham, London.

 

[VanguardLH]

No, the reg key / value that you mention [IconStream] is responsible for
maintaining and reproducing the list found in :

TaskBar Control Panel > Hide Inactive Icons >
Customize

...shows a list of both "Current Icons" and "Past Icons" together with
check-boxes to enable / disable said icons from being shown by default
(when the "Hide Inactive Icons" feature is invoked), and it's these lists
of icons that are defined by the key / values :

[HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TrayNotify]

..."IconStreams" and " PastIconStreams" respectively, and has nothing at
all to do with actually holding icons in the actual Taskbar Notification
Area itself, just the lists in the Taskbar's "Customize Notifications"
control.

("Customize Notifications" Screenshot)
http://twitpic.com/azkzn9

==

Cheers, Tim Meddick, Peckham, London.

My guess (without using the software to monitor its registry accesses
via SysInternals' RegMon or ProcMon) is that they read the following
registry entry:

Key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TrayNotify
Data item: IconStreams

I don't know what is the structure for this string but looking at it
shows some text that describes icons for the programs that I see in the
system tray.

Yes, Customize does show the current and past icon histories. The
current list does NOT list just the visible tray icons. The current
list is ALL tray icons in the system tray regardless of whether their
state is visible or hidden. Even if you configure Windows to NOT hide
inactive icons, the list of all CURRENT tray icons is still listed in
that registry key. That a tray icon has an always-show, always-hide, or
hide-when-inactive attribute does NOT remove it from the current list.

That is *Windows* list of tray icons (whether they have the always-show,
always-hide, or hide-when-inactive attribute). You can delete those
registry keys but that won't make the tray icons disappear. You can use
a policy to completely hide the system tray but that doesn't preclude
the *current* (active) tray icons from getting listed in the IconStreams
registry data item; see
http://samanathon.com/registry-hack-hide-all-icons-in-the-notification-area-system-tray/.
When you disable or delete that policy and relogin, poof, all those tray
icons are still there in the system tray and the IconStreams still lists
all those currently active tray icons. Even when the system tray is not
visible via policy, IconStreams will still get populated with ALL the
currently existing tray icons (as the apps populate the system tray with
their call to Shell_NotifyIcon). The apps manage their own tray icons
through the Shell_NotifyIcon system call:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb762159(v=vs.85).aspx

The IconStreams data item is just a list. It is not a control over the
*existence* of the tray icons. It probably does contain the display
state attribute (always-on, always-hide, hide-when-inactive) but that
doesn't change that ALL tray icons will be listed in this data item.
Since it is just a list, it doesn't manage whether the tray icons exist
or not. It can only affect whether they are visible or not as an
attribute list employed by the Windows taskbar on HOW it shows those
existing tray icons.

If you delete the IconStreams data item from the registry, and you load
a *fresh* instance of JAWS (so it never saw a prior list of tray icons),
does it still list all the tray icons (whether they are visible or
hidden)? If so, what do YOU see (using something like SysInternals'
ProcMon) for where JAWS interrogates the registry to get a list of the
tray icons? I showed where is maintained a *list* of current icons
(whether hidden or visible). This is not a control over what tray icons
that can exist. If you think some other registry value holds the
current list of tray icons that a program can interrogate then please
enlighten us.

 

[VanguardLH]

In message <[email protected]>, VanguardLH <[email protected]>
writes:
[]

:

JAWS, the screen-access (via speech and/or Braille) for the blind
system, has a means to access what's in the tray; when this means is
being accessed, a sighted person can see that there is popped-up a text
list of the icons, along with ways to access them (such as left or right
click).

I presume the other access softwares (Window-Eyes, NVDA?, etc.) have
something similar.

It might be interesting to know how this list is generated - in other
words, whether it just uses the icons that are visible in the tray (in
which case it'd be susceptible to the same problems of inadequate
refresh etc.), or whether it uses a different means to see what _should_
be there. If the latter, it might help (to know what that means is).

My guess (without using the software to monitor its registry accesses
via SysInternals' RegMon or ProcMon) is that they read the following
registry entry:

Key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TrayNotify
Data item: IconStreams

I don't know what is the structure for this string but looking at it
shows some text that describes icons for the programs that I see in the
system tray.

[]
If you delete the IconStreams data item from the registry, and you load
a *fresh* instance of JAWS (so it never saw a prior list of tray icons),
does it still list all the tray icons (whether they are visible or
hidden)? If so, what do YOU see (using something like SysInternals'
ProcMon) for where JAWS interrogates the registry to get a list of the
tray icons? I showed where is maintained a *list* of current icons
(whether hidden or visible). This is not a control over what tray icons
that can exist. If you think some other registry value holds the
current list of tray icons that a program can interrogate then please
enlighten us.

I'm afraid I (it was I who mentioned JAWS in the first place) don't have
JAWS; I've just observed my blind friend using it. So I'm afraid I can't
answer your question. (JAWS costs hundreds of pounds.) It was also not
me that suggested which key (or ...) JAWS is using, sorry.

(I only mentioned it as a possible route to a list of icons that
_should_ be in the tray. Which several of you seem to know more about
than I do, which isn't difficult as "I know natheeng"!)

It would be interesting to know from where in the registry these types
of programs are retrieving the list of "current" tray icons (where
"current" just means from some list and may not actually reflect what
tray icons are actually available whether visible or not). I'm curious
now and will see is some system tray utility (that, for example, rolls
the tray icons into its own menu to reduce the size of the system tray)
might go reading the registry. I can then use SysInternals' ProcMon to
check what in the registry is getting access by that tray utility.

 

[Char Jackson]

In message <[email protected]>, VanguardLH <[email protected]>
writes:
[]

:

JAWS, the screen-access (via speech and/or Braille) for the blind
system, has a means to access what's in the tray; when this means is
being accessed, a sighted person can see that there is popped-up a text
list of the icons, along with ways to access them (such as left or right
click).

I presume the other access softwares (Window-Eyes, NVDA?, etc.) have
something similar.

It might be interesting to know how this list is generated - in other
words, whether it just uses the icons that are visible in the tray (in
which case it'd be susceptible to the same problems of inadequate
refresh etc.), or whether it uses a different means to see what _should_
be there. If the latter, it might help (to know what that means is).

My guess (without using the software to monitor its registry accesses
via SysInternals' RegMon or ProcMon) is that they read the following
registry entry:

Key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TrayNotify
Data item: IconStreams

I don't know what is the structure for this string but looking at it
shows some text that describes icons for the programs that I see in the
system tray. []
If you delete the IconStreams data item from the registry, and you load
a *fresh* instance of JAWS (so it never saw a prior list of tray icons),
does it still list all the tray icons (whether they are visible or
hidden)? If so, what do YOU see (using something like SysInternals'
ProcMon) for where JAWS interrogates the registry to get a list of the
tray icons? I showed where is maintained a *list* of current icons
(whether hidden or visible). This is not a control over what tray icons
that can exist. If you think some other registry value holds the
current list of tray icons that a program can interrogate then please
enlighten us.

I'm afraid I (it was I who mentioned JAWS in the first place) don't have
JAWS; I've just observed my blind friend using it. So I'm afraid I can't
answer your question. (JAWS costs hundreds of pounds.) It was also not
me that suggested which key (or ...) JAWS is using, sorry.

(I only mentioned it as a possible route to a list of icons that
_should_ be in the tray. Which several of you seem to know more about
than I do, which isn't difficult as "I know natheeng"!)

It would be interesting to know from where in the registry these types
of programs are retrieving the list of "current" tray icons (where
"current" just means from some list and may not actually reflect what
tray icons are actually available whether visible or not). I'm curious
now and will see is some system tray utility (that, for example, rolls
the tray icons into its own menu to reduce the size of the system tray)
might go reading the registry. I can then use SysInternals' ProcMon to
check what in the registry is getting access by that tray utility.

To my way of thinking, that kind of information has no business being
in the registry. It should be stored in RAM, along with the list of
process IDs, open file handles, etc.

 

[VanguardLH]

To my way of thinking, that kind of information has no business being
in the registry. It should be stored in RAM, along with the list of
process IDs, open file handles, etc.

From the following forum thread:

http://social.msdn.microsoft.com/Fo.../thread/4c4f60ce-3573-433d-994e-9c17f95187f0/

you first get the handle to the systray object. Apparently you then
look for "button" objects in the systray (so maybe the tray icons are
handled like button objects within the systray window). More info at:

http://www.codeproject.com/Articles/10807/Shell-Tray-Info-Arrange-your-system-tray-icons

goes beyond just the code to get the systray window handle and
mentioning the TBBUTTON structure to retrieve by showing the code.

So to find the tray icons and their owner processes requires digging in
the window handles and those are in memory (but off in some OS managed
area I don't know about). So finding them is not by looking in the
registry other than they do get listed in IconStreams to associate the
visible attribute upon then so the Windows taskbar knows how to handle
them.

 

[Tim Meddick]

That's exactly what I meant - the icons described in the "IconStreams" and
"PastIconStreams" registry values are *only* linked with the lists that
appear in the "Customize Notifications" control :

"Control Panel" > "Taskbar and Start Menu Properties" >
"Taskbar" (Tab) > "Hide Inactive Icons" / Customize (Button)

....and are *not* linked with the appearance [or not] of icons in the
Notification Area [tray] itself.

==

Cheers, Tim Meddick, Peckham, London.

 

[VanguardLH]

That's exactly what I meant - the icons described in the "IconStreams" and
"PastIconStreams" registry values are *only* linked with the lists that
appear in the "Customize Notifications" control :

And how would those lists get built? The process calling NotifyIcon()
doesn't modify those lists. I checked a couple of programs that add
tray icons and they don't access the IconStreams registry data item;
i.e., the processes creating tray icons don't update that registry item.
So something else has to build that list and which is independent of the
existence of the tray icons since deleting the list doesn't make the
tray icons go away. Windows builds the list in the background, perhaps
as an action performed by the owning app calling the NotifyIcon API.

"Control Panel" > "Taskbar and Start Menu Properties" >
"Taskbar" (Tab) > "Hide Inactive Icons" / Customize (Button)

...and are *not* linked with the appearance [or not] of icons in the
Notification Area [tray] itself.

See my earlier reply to Char. I installed PS Tray Factory in a virtual
machine along with SysInternals' ProcessExplorer to monitor the .exe for
PS Tray Factory for what registry keys & items it accesses. I never saw
it access the IconStreams registry item. So something ELSE is building
that IconStreams list, like Windows itself when a process requests
adding a tray icon.

So I took a different tack on Google searches by looking for code
examples that attempt to retrieve a list of currently existing tray
icons. That's in my reply to Char; however, it doesn't address how the
IconStreams list gets built. Maybe Windows does the same windows handle
search as the example code to find what is the current processes that
own a window handle which is a button object in the systray window. If
that were true, however, then it doesn't explain why Windows doesn't
always update the systray so the icons are always there or why they
sometimes stick around when the process unloads that owns the tray icon.
So my bet is on Windows building its IconStreams list when the process
calls NotifyIcon() to create the button object in the systray window.