Hi!

After finishing all tasks running under 7.0.28, I downloaded, installed and then launched 7.0.64. My system has been "connecting to localhost" for well over 10 minutes. Obviously something is wrong. I re-installed 7.0.64 using the repair option, but still cannot connect to localhost. I did make a backup of the BOINC 7.0.28 folder prior to the installation of 7.0.64. Any ideas / suggestions on what to do from here? Thanks in advance!

System:
Windows 7 Ultimate SP1 (updated prior to install)
Intel Core i7 990X
24GB RAM
ASUS Rampage III Formula Motherboard
2 EVGA GTX680 Video cards
Direct X Version 11

"Update prior to install" i.e. the environment did change. But, propose you uninstall and install again, making sure to select in the Advanced screen "Allow all users". Very possibly the account from which you installed was not added. Also, was this installed as service [which disables GPGPU computing on Windows]? This is done in same screen as where you choose the "Allow all users".

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

I did select "Allow all users" and did not install as a service during both the initial install and the "Repair" install. I will try it again as you propose. If need be, I could uninstall BOINC completely, including editing the registry, and do a clean install, but if there is another way, I'm certainly willing to give it a try.

Oddly, I installed 7.0.64 on a nearly identical system without a problem. The only difference being the use of 2 EVGA GTX580 video cards. Knowing that each system varies, I just found that interesting.

Did you ever allow BOINC.exe and BOINCMGR.exe to communicate with each other on TCP port 31416 in your firewall?

If you had already done that at one time:
1. Did you install the correct version of BOINC this time, not that you had a 64bit version and now installed a 32bit version, or you had a 32bit version and now installed a 64bit version?

I ask as the 32bit version installs to a different program directory than the 64bit version does. 32bit programs install to C:\Program Files (x86)\ in Windows, while 64bit programs install to C:\Program Files\
Notice the difference? You can't install programs of a differing bit-size to the other directory either, Windows won't let you.

So if you had 32bit Windows installed and now installed 64bit Windows, it will make a problem for the firewall exclusion, as there the programs are filled in with full path to their directory. And so if the firewall says it's fine to let C:\Program Files (x86)\BOINC\boinc.exe communicate with C:\Program Files (x86)\BOINC\boincmgr.exe, but your new BOINC is installed into C:\Program Files\BOINC\, the firewall won't allow the communication.

In cases like this you better check what the firewall says it allows.

2. Did you have a GPU installed, but did the Windows Update disable it, install a new driver for it by chance? There have been reports where the client and manager stop communicating with each other, when it's found that the GPU that was used earlier for calculations, is all of a sudden gone. This causes infinite RPCs, which make it impossible for the client to communicate with the manager.

---

Did you ever allow BOINC.exe and BOINCMGR.exe to communicate with each other on TCP port 31416 in your firewall?

If you had already done that at one time:
1. Did you install the correct version of BOINC this time, not that you had a 64bit version and now installed a 32bit version, or you had a 32bit version and now installed a 64bit version?

I ask as the 32bit version installs to a different program directory than the 64bit version does. 32bit programs install to C:\Program Files (x86)\ in Windows, while 64bit programs install to C:\Program Files\
Notice the difference? You can't install programs of a differing bit-size to the other directory either, Windows won't let you.

So if you had 32bit Windows installed and now installed 64bit Windows, it will make a problem for the firewall exclusion, as there the programs are filled in with full path to their directory. And so if the firewall says it's fine to let C:\Program Files (x86)\BOINC\boinc.exe communicate with C:\Program Files (x86)\BOINC\boincmgr.exe, but your new BOINC is installed into C:\Program Files\BOINC\, the firewall won't allow the communication.

In cases like this you better check what the firewall says it allows.

I had not changed anything with regards to the firewall. I had been running boinc7.0.28_windows_x86_64 and downloaded / installed boinc7.0.64_windows_x86_64. Just checked the firewall settings for BOINC.EXE and BOINCMGR.exe and both are set to use any TCP port.

2. Did you have a GPU installed, but did the Windows Update disable it, install a new driver for it by chance? There have been reports where the client and manager stop communicating with each other, when it's found that the GPU that was used earlier for calculations, is all of a sudden gone. This causes infinite RPCs, which make it impossible for the client to communicate with the manager.

Two EVGA GTX680 video cards were already installed and running under nVidia driver version 314.07. I tried to update to the newest version (314.22) but the update stopped with a message about not having the correct hardware. I need to investigate that further when I can.

Just for the heck of it, I uninstalled 7.0.64(x64) and re-installed 7.0.28(x64), downloaded a few SETI WUs and everything is working properly. Fortunately, the WUs are all shorties and I've selected NNTs. When they complete and upload, I'll have another go at 7.0.64. It shouldn't be too long.

That the client cannot communicate with the manager won't affect the running of any work. You can just start boinc.exe and it'll do all work in the background. BOINC Manager is just a graphical interface to control the client.

As far as I know, there have been no fixes for or work done on the communication between the client and the manager for any BOINC between 7.0.28 and 7.0.64. We've been doing different bug fixes.

So what you can try to do is remove the BOINC entries in the firewall and re-allow them after installing 7.0.64

You're using Windows firewall?

---

So what you can try to do is remove the BOINC entries in the firewall and re-allow them after installing 7.0.64

You're using Windows firewall?

Yes, I'm using Windows firewall. I know it's better than nothing (barely). Do you have a recommendation for another?

With severe thunderstorms in the area last night, I decided to shutdown and wait until this morning to continue. I again downloaded and re-installed 7.0.64(x64) with the same result (long period of Connecting to localhost).

Uninstalled 7.0.64, removed BOINC entries in the firewall, then re-installed 7.0.64 (BOINC entries restored to the firewall) again with the same result (attempting to connect to localhost but not able to connect). It may or may not be significant but the message "unable to connect to localhost" does not ever appear. Only "connecting to localhost" for upwards of 10 minutes before I exit BOINCMGR.

I've tried uninstalling 7.0.64 and re-installing into an empty BOINC folder/directory with the same result. Do you have any other ideas about things to try? If we can learn something from this, it will be well worth it.

BOINC its parts use TCP port 31416 to communicate with each other. Is it possible something else on your system has started up before BOINC and is using that port?

Can you open a command line window (Start->Run->type cmd and hit Enter) and type in netstat -an and hit Enter. In the list that shows, is there an entry for 127.0.0.1:31416 in both the IP address columns?

We can also see what program opens up what ports. But for this we need to elevate the command line to administrator. So go Start->All programs->Accessories->Right click on Command Prompt->Run as administrator->Acknowledge.

Next type netstat -bn and hit Enter.
What are the entries for boinc.exe?
If you want, you can let the output go to a text file so it's easier to copy data from it. In that case, do netstat -bn > C:\temp\netstat.txt

---

BOINC its parts use TCP port 31416 to communicate with each other. Is it possible something else on your system has started up before BOINC and is using that port?

Can you open a command line window (Start->Run->type cmd and hit Enter) and type in netstat -an and hit Enter. In the list that shows, is there an entry for 127.0.0.1:31416 in both the IP address columns?

Active Connections

Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING
TCP 0.0.0.0:8443 0.0.0.0:0 LISTENING
TCP 0.0.0.0:8845 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49154 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49155 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49165 0.0.0.0:0 LISTENING
TCP 127.0.0.1:2559 0.0.0.0:0 LISTENING
TCP 127.0.0.1:31416 0.0.0.0:0 LISTENING
TCP [::]:135 [::]:0 LISTENING
TCP [::]:445 [::]:0 LISTENING
TCP [::]:5357 [::]:0 LISTENING
TCP [::]:49152 [::]:0 LISTENING
TCP [::]:49153 [::]:0 LISTENING
TCP [::]:49154 [::]:0 LISTENING
TCP [::]:49155 [::]:0 LISTENING
TCP [::]:49165 [::]:0 LISTENING
UDP 0.0.0.0:500 *:*
UDP 0.0.0.0:3702 *:*
UDP 0.0.0.0:3702 *:*
UDP 0.0.0.0:4500 *:*
UDP 0.0.0.0:49927 *:*
UDP 127.0.0.1:1900 *:*
UDP 127.0.0.1:48000 *:*
UDP 127.0.0.1:48001 *:*
UDP 127.0.0.1:64122 *:*
UDP [::]:500 *:*
UDP [::]:3702 *:*
UDP [::]:3702 *:*
UDP [::]:4500 *:*
UDP [::]:49928 *:*
UDP [::1]:1900 *:*
UDP [::1]:64121 *:*

We can also see what program opens up what ports. But for this we need to elevate the command line to administrator. So go Start->All programs->Accessories->Right click on Command Prompt->Run as administrator->Acknowledge.

Next type netstat -bn and hit Enter.
What are the entries for boinc.exe?
If you want, you can let the output go to a text file so it's easier to copy data from it. In that case, do netstat -bn > C:\temp\netstat.txt

Active Connections

Proto Local Address Foreign Address State
TCP 127.0.0.1:2559 127.0.0.1:54674 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54675 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54676 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54677 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54686 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54687 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54688 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54689 TIME_WAIT

Sorry. Couldn't figure out how to space the columns properly.

What I see there, is that all of your ports are blocked. Let me check up on that (after dinner).

---

Jord,

Once again, I re-installed 7.0.28(x64) and not as a service. I did nothing else. Following your previous instructions, here are the results from running netstat -an

Active Connections

Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING
TCP 0.0.0.0:8443 0.0.0.0:0 LISTENING
TCP 0.0.0.0:8845 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49154 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49155 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49165 0.0.0.0:0 LISTENING
TCP 127.0.0.1:2559 0.0.0.0:0 LISTENING
TCP 127.0.0.1:2559 127.0.0.1:55035 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:55036 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:55037 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:55038 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:55039 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:55040 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:55041 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:55042 TIME_WAIT
TCP 127.0.0.1:31416 0.0.0.0:0 LISTENING
TCP 127.0.0.1:31416 127.0.0.1:55018 ESTABLISHED
TCP 127.0.0.1:55018 127.0.0.1:31416 ESTABLISHED
TCP 192.168.1.69:139 0.0.0.0:0 LISTENING
TCP 192.168.1.69:54291 184.30.7.117:80 CLOSE_WAIT
TCP 192.168.1.69:54293 64.145.84.59:80 CLOSE_WAIT
TCP [::]:135 [::]:0 LISTENING
TCP [::]:445 [::]:0 LISTENING
TCP [::]:5357 [::]:0 LISTENING
TCP [::]:49152 [::]:0 LISTENING
TCP [::]:49153 [::]:0 LISTENING
TCP [::]:49154 [::]:0 LISTENING
TCP [::]:49155 [::]:0 LISTENING
TCP [::]:49165 [::]:0 LISTENING
UDP 0.0.0.0:68 *:*
UDP 0.0.0.0:500 *:*
UDP 0.0.0.0:3702 *:*
UDP 0.0.0.0:3702 *:*
UDP 0.0.0.0:3702 *:*
UDP 0.0.0.0:3702 *:*
UDP 0.0.0.0:4500 *:*
UDP 0.0.0.0:5355 *:*
UDP 0.0.0.0:49927 *:*
UDP 0.0.0.0:51340 *:*
UDP 0.0.0.0:55368 *:*
UDP 127.0.0.1:1900 *:*
UDP 127.0.0.1:48000 *:*
UDP 127.0.0.1:48001 *:*
UDP 127.0.0.1:54798 *:*
UDP 127.0.0.1:57228 *:*
UDP 192.168.1.69:137 *:*
UDP 192.168.1.69:138 *:*
UDP 192.168.1.69:1900 *:*
UDP 192.168.1.69:54797 *:*
UDP [::]:500 *:*
UDP [::]:3702 *:*
UDP [::]:3702 *:*
UDP [::]:3702 *:*
UDP [::]:3702 *:*
UDP [::]:4500 *:*
UDP [::]:5355 *:*
UDP [::]:49928 *:*
UDP [::]:51341 *:*
UDP [::]:55369 *:*
UDP [::1]:1900 *:*
UDP [::1]:54796 *:*
UDP [fe80::11c:87fa:5b32:ed80%16]:546 *:*
UDP [fe80::11c:87fa:5b32:ed80%16]:1900 *:*
UDP [fe80::11c:87fa:5b32:ed80%16]:54795 *:*

Here are the results from running netstat -bn

Active Connections

Proto Local Address Foreign Address State
TCP 127.0.0.1:31416 127.0.0.1:55018 ESTABLISHED
[boinc.exe]
TCP 127.0.0.1:55018 127.0.0.1:31416 ESTABLISHED
[boincmgr.exe]
TCP 192.168.1.69:54291 184.30.7.117:80 CLOSE_WAIT
[vprot.exe]
TCP 192.168.1.69:54293 64.145.84.59:80 CLOSE_WAIT
[vprot.exe]

Again, these results are from having 7.0.28 installed. Just thought I'd show you this for a comparison. Maybe it will shed some light on this.

Also, I have a nearly identical system to this one. The other is running 2 EVGA GTX580 cards (Fermi) while this one runs 2 EVGA GTX680 cards (Kepler). The Fermi system updated to 7.0.64(x64) without a problem. Could the Kepler cards be part of this problem? Just wondering...

Rich

Is Boinc.exe even running?, are project apps running? Perhaps the the 7.0.64 Boinc.exe is crashing, Boinc Manager is never going to connect to a client that isn't running.

Claggy

Proto  Local Address          Foreign Address        State
  TCP    127.0.0.1:2559         127.0.0.1:54674        TIME_WAIT
  TCP    127.0.0.1:2559         127.0.0.1:54675        TIME_WAIT
  TCP    127.0.0.1:2559         127.0.0.1:54676        TIME_WAIT
  TCP    127.0.0.1:2559         127.0.0.1:54677        TIME_WAIT
  TCP    127.0.0.1:2559         127.0.0.1:54686        TIME_WAIT
  TCP    127.0.0.1:2559         127.0.0.1:54687        TIME_WAIT
  TCP    127.0.0.1:2559         127.0.0.1:54688        TIME_WAIT
  TCP    127.0.0.1:2559         127.0.0.1:54689        TIME_WAIT

Hold on, these results from 7.0.64, are these the addresses it says boinc.exe is using?

---

Are you running rosetta, by chance? I had the same issue after installing the new version. After uninstall, deleted data folders, reinstalled, synced w bam and quickly suspended rosetta. So far, so good

Are you running rosetta, by chance? I had the same issue after installing the new version. After uninstall, deleted data folders, reinstalled, synced w bam and quickly suspended rosetta. So far, so good

Is Boinc.exe even running?, are project apps running? Perhaps the the 7.0.64 Boinc.exe is crashing, Boinc Manager is never going to connect to a client that isn't running.

Boinc.exe, boincmgr.exe and boinctray.exe are all listed in the Windows Task Manager Processes list. All are shown using 00 (zero) CPU and 0:00:00 CPU Time even after several minutes of "connecting to localhost". No project apps are running. SETI@home is the only project I run and use only stock apps at stock speeds. I've never tried using optimized apps, Lunatics or any other, on any system. Since "connecting to localhost" is displayed in the bottom right of the BOINC Manager window, nothing else is running with the exception of the System Idle Process (using 99 CPU). Under the Windows Task Manager Applications tab, it shows that BOINC Manager is running.

Proto Local Address Foreign Address State
TCP 127.0.0.1:2559 127.0.0.1:54674 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54675 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54676 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54677 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54686 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54687 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54688 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:54689 TIME_WAIT


Hold on, these results from 7.0.64, are these the addresses it says boinc.exe is using?

I don't know what is using those addresses. I shutdown the system last night due to severe thunderstorms here, re-booted and re-installed 7.0.64(x64) again this morning, ran netstat -bn as per your previous instructions, and this is what is displayed:

Active Connections

Proto Local Address Foreign Address State
TCP 127.0.0.1:2559 127.0.0.1:57340 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:57341 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:57342 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:57343 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:57350 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:57351 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:57352 TIME_WAIT
TCP 127.0.0.1:2559 127.0.0.1:57353 TIME_WAIT
TCP 192.168.1.69:49442 184.30.7.117:80 CLOSE_WAIT
[vprot.exe]
TCP 192.168.1.69:49444 165.254.29.59:80 CLOSE_WAIT
[vprot.exe]
TCP 192.168.1.69:57163 128.32.18.189:80 TIME_WAIT

As you can see, those listed under Foreign Address have changed. Perhaps the reboot and re-installation of 7.0.64 accounts for that? As for what is using those addresses, I have no idea. How can I find out?

Rich

No project apps are running.

Well, boinc.exe, boincmgr.exe and boinctray.exe shouldn't use any CPU cycles, but it is weird that your science apps aren't running, unless you set preferences for them to start only when the computer is idle (did you?).

If not, there's something locking your BOINC. What that is, I don't know, I am rapidly running out of ideas. I'll ask the developer for Windows to make a pass-by, maybe that he has any ideas.

---

Can you post the Boinc startup log for Boinc 7.0.28 and for 7.0.64, you'll find the log in the following directory (assuming you installed it in the default location):

C:\ProgramData\BOINC

the directory is a hidden directory, so you'll need to unhide it or paste the directory straight into explorer, the file you need is stdoutdae.txt (older entries are in stdoutdae.old), the first 30 lines will do.

Claggy

Are you running rosetta, by chance? I had the same issue after installing the new version. After uninstall, deleted data folders, reinstalled, synced w bam and quickly suspended rosetta. So far, so good

BIOOYA,
I'm not running Rosetta. It may eventually come down to what you suggested, but I want to give Ageless, Claggy or any of the devs / testers out there an opportunity to see what they come up with for this problem. It may be a fluke with my system. I haven't written code in years, but I know that there is always just one more bug. Not saying that there is in this case. There may be something that can be learned from this and used to help others in the future.

Rich