12-14-2019, 08:10 AM
(This post was last modified: 12-14-2019, 08:15 AM by Dean Roddey.)
The system tray manager apparently doesn't watch the applications all the time. If one dies without shutting down cleanly, it will not know that. When you over it tries to find it and can't, and then removes the icon.
Sleep is a messy business and it's incredibly difficult to find subtle bugs that happen because of the weirdness that goes on when a system goes to sleep. There's no reasonable way to debug such things. Sleeping isn't something that's friendly to more complex programs that are talking other things and other things are talking to it and such. They cannot just shut down on a moment's notice, but Windows will just stop them almost immediately and leave them in whatever weird state they happen to be in, because they want client type systems to be able to go to sleep very quickly. It's hard to say what will happen if a program is then resurrected in almost any potential state because it wasn't able to clean up completely before it got frozen.
So I wouldn't be totally shocked if it happened once in a while coming out of sleep. But, in terms of just a non-sleeping system, if it falls over then, I'd assign it to some more fundamental issue with the tray monitor, but never found one despite years of looking. The task scheduler killing might explain why that is.
Of course when it would fall over, folks would probably restart it manually. Then it wouldn't be running under the task scheduler and wouldn't get stopped by it, and would run fine. Then at some point they'd log out and back in and it would be back on the death watch again. So that would explain some of the (seeming) unpredictability of it, if that is indeed what is happening.
Sleep is a messy business and it's incredibly difficult to find subtle bugs that happen because of the weirdness that goes on when a system goes to sleep. There's no reasonable way to debug such things. Sleeping isn't something that's friendly to more complex programs that are talking other things and other things are talking to it and such. They cannot just shut down on a moment's notice, but Windows will just stop them almost immediately and leave them in whatever weird state they happen to be in, because they want client type systems to be able to go to sleep very quickly. It's hard to say what will happen if a program is then resurrected in almost any potential state because it wasn't able to clean up completely before it got frozen.
So I wouldn't be totally shocked if it happened once in a while coming out of sleep. But, in terms of just a non-sleeping system, if it falls over then, I'd assign it to some more fundamental issue with the tray monitor, but never found one despite years of looking. The task scheduler killing might explain why that is.
Of course when it would fall over, folks would probably restart it manually. Then it wouldn't be running under the task scheduler and wouldn't get stopped by it, and would run fine. Then at some point they'd log out and back in and it would be back on the death watch again. So that would explain some of the (seeming) unpredictability of it, if that is indeed what is happening.
Dean Roddey
Explorans limites defectum
Explorans limites defectum