problem with boinctray.exe

[Beyond]

There's a problem with boinctray.exe.  It doesn't unload when boinc is closed.  Sometimes boincmgr will refuse to reconnect to the client until the boinctray process is killed manually.  It's been reported, nobody ever fixes the problem.  This has been going on for a long time.  Kind of irritating.

[Pepo]

There's a problem with boinctray.exe.  It doesn't unload when boinc is closed.  Sometimes boincmgr will refuse to reconnect to the client until the boinctray process is killed manually.  It's been reported, nobody ever fixes the problem.  This has been going on for a long time.  Kind of irritating.

I seem to have quite opposite problem. WinXP Pro SP3. Yesterday (on 10.2.) I've installed (my user has admin privileges) newer BOINC version (6.12.14, built on 8.2.) on my home machine. The new Manager connected without problem. But other logged-in user's boinctray.exe is still running (probably the previous 6.12.11? how to find out from the process' memory or opened handles?) since having logged in on 6.2. Apparently the installer killed just my user's Manager and boinctray and the client with apps, running as a client... OTOH I can not imagine that the installer would make the effort and start killed boincmgr processes for other users, which it would have killed prior to installation

Funny that it was able to delete the executable file, although there is still one process running from it. When I try to do it as an admin, "the file is locked agains writes". Have the OS not needed to keep the file, while its code is mapped to the process' memory? I know that Unices can keep file's inode (and data) until all references are over, although the file is being deleted from a folder, but did not know about such filesystem functionality under Windows. Someone else an idea?

According to SysInternals' VMMap, the executable's file is not mapped to memory. Whereas my user's boinctray.exe is mapped to memory

[Beyond]

Not totally following what you're trying to say but boinctray.exe is installed at boot and nothing seems to stop it until you kill it manually.  I've even started killing it prior to BOINC client re-installs.  Commenting boinctray.exe out in startup ends the boincmgr reconnection problems here.  Unfortunately it gets re-installed in startup with every new version install 

[Pepo]

Not totally following what you're trying to say

Sorry, just thinking too loud and turning my surprised head from oneside to another (Maybe a moderator should place our conversation in a separate thread?)

but boinctray.exe is installed at boot

It doesn't unload when boinc is closed.

Rather a private copy started at each user's login? IIRC it is not meant to close until a user logs out.

Sometimes boincmgr will refuse to reconnect to the client until the boinctray process is killed manually.  It's been reported, nobody ever fixes the problem.  This has been going on for a long time.  Kind of irritating.

You are right that THIS shoult really not happen. (If it happens. I did not have such problem yet.)

and nothing seems to stop it until you kill it manually.  I've even started killing it prior to BOINC client re-installs.  Commenting boinctray.exe out in startup ends the boincmgr reconnection problems here.  Unfortunately it gets re-installed in startup with every new version install 

The devs are convinced that it is necessary to run boinctray for each user, otherwise they can not promise that "pause science apps unless all users are idle" functionality can be assured (especially if one user is running BOINC and an other one is active).

For a single-user machine running the client as a Manager's child process, the boinctray is possibly really no necessary at all...

[Beyond]

For a single-user machine running the client as a Manager's child process, the boinctray is possibly really no necessary at all...

AFAIK it was added to solve some problem in Vista (I believe you're correct about user switching).  It is at least one of the causes of boinc manager reconnection problems.  Wish they would at least make it optional as it's been a nagging problem since introduced.