You spend ten minutes in the taskbar settings carefully promoting your VPN client, monitoring agent, and audio device icons to “always show.” You restart for a driver update. You come back and three of them are gone again, buried in the overflow flyout where you have to hunt for them. The apps themselves are running fine. Their icons simply lost the promotion they had five minutes earlier.
This is not bad luck. It is the documented behavior of the Windows notification area.
How the Notification Area Actually Stores State
The system tray (notification area) is controlled by a small set of structures under the current user registry hive, primarily:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\TrayNotify- The binary values
IconStreamsandPastIconsStream
IconStreams is the active map. It contains entries that associate an application identity (class name, executable path, or a more opaque identifier the shell derives) with a visibility or promotion flag. PastIconsStream keeps historical entries so that icons that have appeared before can be recognized and placed according to prior user preference or default policy.
Apps register their icons at runtime by calling Shell_NotifyIcon. The shell consults the current streams, any explicit user settings in the taskbar configuration UI, and internal heuristics that decide whether an icon should appear in the main tray, the overflow, or be hidden entirely.
The critical detail is that these streams are not treated as durable user configuration that the shell is obligated to preserve. They are working state that the shell is free to reconcile, rebuild, or partially discard whenever it decides the notification area needs to be “cleaned up.”
Why Every Update and Restart Wipes Your Rules
Feature updates, large cumulative updates, and even some Explorer restarts trigger a reset or partial rebuild of the TrayNotify data. The reasons are architectural rather than malicious:
- During a feature update the shell migration code often starts from a conservative “known good” notification area layout and re-registers icons as background processes come back online.
- App identities can change subtly after an update (different path, different publisher, new version in the executable metadata). The binary blob no longer matches the old entry, so the promotion is lost.
- Timing races on resume or post-update boot mean some icons register after the shell has already decided the final visible set.
- Ghost entries from previously uninstalled apps are deliberately kept for a while to avoid flicker, which makes the stream larger and the reconciliation logic more conservative.
The result is that “always show” settings you set through the normal Windows UI are not first-class persistent preferences. They are suggestions written into a cache-like structure that the shell is allowed to forget.
This is why the same icons keep disappearing for the same users on the same machines after every Patch Tuesday or major build.
The Ghost Icon Problem
Ghost icons are the stale entries that survive in PastIconsStream long after the corresponding application has been uninstalled or updated to a different identity. They clutter the overflow menu and sometimes cause duplicate or missing glyphs.
The shell’s built-in cleanup is intentionally conservative. It does not aggressively delete entries because doing so can cause temporary disappearance of legitimate icons during normal app lifecycle events. Users are left with a slowly growing list of dead icons that no amount of manual “turn system icons on or off” toggling fully resolves.
Why Manual Registry Edits and Patcher Tools Are Different Approaches
People who dig into this problem usually land on one of two families of solutions.
Direct registry manipulation (deleting or editing IconStreams and PastIconsStream) can clear the slate. It is also the definition of brittle. The binary format is undocumented, shifts between Windows builds, and offers no safety net. A mistimed edit combined with an Explorer restart can leave the tray in a worse state than before.
Patcher tools such as Windhawk scripts or ExplorerPatcher take a different route. They inject code or replace shell components to change how the notification area behaves in real time. This can give persistent “always show” behavior without relying on the shell’s own streams. The cost is higher: these approaches often require administrator privileges for injection, run with a larger attack surface on every Explorer restart, and can break silently when Microsoft changes internal structures in the next cumulative update. They are powerful but fundamentally different in risk profile from a tool that only observes and re-applies state through documented interfaces.
How a Re-Application Engine Makes Rules Durable
A different architecture separates the user’s intent from the shell’s ephemeral streams.
Instead of trying to edit the binary blobs directly or patch the shell, you store the desired rule (Always show, Hide, or Default) for each application identity in a separate, durable location controlled by the utility. Then, after any event that is known to reset the notification area, the utility re-asserts the desired visibility state using the public mechanisms the shell provides for icon registration and modification.
The key behaviors required for this to be reliable are:
- Detection of the moments when the shell is likely to have reset (pre-update snapshots, pre-restart triggers, and post-restart observation).
- A pre-change snapshot so that even the act of applying tray rules is itself reversible.
- A short verification window after the re-application so the tool knows whether the change actually took effect.
- A ghost-sweep operation that can remove stale entries while offering an immediate undo path if something useful was removed by mistake.
When these pieces are present, the user’s “always show” decisions become durable across the exact events that previously erased them.
If your VPN, monitoring, or audio icons keep vanishing into the overflow after every update, the combination of durable per-app rules plus automatic re-application after shell resets is available in
Get Taskbar Sentinel on Microsoft Store
Real Workflows That Depend on Tray Persistence
Security and operations teams rely on endpoint agents and VPN clients whose tray icons must remain one click away even after updates. Power users with many background services need durable “always visible” or “hide” decisions for audio tools, sync clients, and hardware monitors. Multi-monitor and dock/undock users encounter the well-known duplication bug; a rule re-application engine can restore the icons that matter without forcing the user to reconfigure after every display change.
Comparison of Approaches
| Approach | Privileges | Survives Updates | Risk on Failure | User Intent Durable | Footprint |
|---|---|---|---|---|---|
| Manual IconStreams edits | Standard | Rarely | High (no rollback) | No | None |
| Windhawk / ExplorerPatcher | Often elevated | Fragile | Medium-High | Yes (patching) | Varies |
| Taskbar Sentinel rules | Standard | Yes (re-applied) | Very low | Yes (stored rules) | ~12 MB |
Patcher tools suit cases where real-time shell behavior must change. A re-application engine suits users who only need their own visibility preferences to survive normal housekeeping.
Limitations That Still Require Honesty
Not every tray state is safely restorable through a lightweight refresh. Deep profile corruption or icons from apps that have not re-registered may still require a sign-out or restart. A responsible tool detects what it can correct and tells the user when a full session reinitialization is the honest next step.
FAQ
Why do my “always show” tray icons keep resetting after Windows updates?
The promotion state lives in IconStreams and PastIconsStream under TrayNotify. These binary structures are working caches that the shell rebuilds or reconciles during feature updates, large cumulative updates, and many Explorer restarts. Windows does not treat a user’s explicit visibility preference as durable configuration that must be preserved.
What exactly are ghost icons and why do they appear?
Ghost icons are stale entries left in PastIconsStream after an application has been uninstalled, updated to a different identity, or simply failed to clean up its registration on exit. The shell keeps them for a while to avoid flicker, which means the overflow menu slowly fills with dead entries that no longer correspond to running processes.
Is it safe to delete IconStreams and PastIconsStream manually?
It can clear stuck state in the moment, but the binary format is undocumented and changes between builds. There is no atomicity guarantee and no rollback. A mistimed deletion combined with an app that registers at the wrong moment can leave you with missing system icons that are harder to recover.
How do patcher tools like Windhawk differ from a rule re-application approach?
Patcher tools modify shell behavior in real time, often through injection or component replacement. This can achieve persistent visibility without relying on the shell’s streams. The trade-off is elevated privileges for many implementations, a larger attack surface on every Explorer cycle, and the possibility of silent breakage on the next Windows build. A re-application engine stores the user’s stated preference separately and re-asserts it through documented APIs after the shell has done its reset.
Can I just use Taskbar settings to keep icons visible?
The built-in “Turn system icons on or off” and per-icon overflow controls are convenient but not durable. They write into the same streams that get rebuilt. If you need the setting to survive the next update or restart without manual intervention, you need something that stores the rule independently and re-applies it.
Does re-applying tray rules require administrator rights?
No. The approach uses the same per-user mechanisms normal apps use to register icons. It runs as a standard user with no UAC prompts.
Keep the Icons You Actually Need Visible
The notification area is one of the most frequently used and least reliable surfaces on a Windows desktop. Every feature update is an opportunity for the shell to forget what you told it last month.
Storing per-app rules outside the shell’s own streams, taking a safety snapshot before every change, and re-asserting those rules after known reset events turns a recurring annoyance into a one-time configuration that actually lasts.
You can read the complete feature list and current pricing on the Taskbar Sentinel product page.
Persistent per-app tray rules with automatic re-application after updates and restarts, plus 60-second ghost sweep undo, are part of
Get Taskbar Sentinel on Microsoft Store
Get Taskbar Sentinel on the Microsoft Store — one-time purchase, 100% offline, no accounts, reversible by design.