FPGA Compile Server Corruption

[tkreider]

Background:

I have a Windows 7 64-bit installation running on an i7-930.  In Oct. I installed LabVIEW FPGA 2009 SP1 Compile Server from a copy of the NI .iso image.

In addition, I have VMWare Player installed with the full development suite installed, targeting the hosts Compile Server.

We pound this system in 'production' for 3 months leading into the New Years holiday...

Issue:

When I returned from the holiday, not a single machine in the plant can hit the compile server on the Win7 host, including the VMWare installed LV tools running on the same PC.  It seems like the clock rolled over from 2010 to 2011 and the compile server went poof!  At first, the compile server complained that the license for Xilinx tools had expired.  Once I reinstalled the compile server, nothing can connect to it, no errors from the server, just network timeouts from the development tool.

Trouble shooting:

Obvious stuff:

   1) 'reboot the machine' done on the VMWare image and the host; no change,

   2) double check virus scanner is off; no change,

   3) double check Windows Firewall is off; no change,

From VMWare, other compile servers on other PC's work fine over the network (so VMWare isn't the issue, but played with bridged vs. NAT anyways; no change),

From VMWare, the 'local host' compile server works fine (remember, this is the one in virtualization, not the VM host version on Win7).

Reinstall compile server; no change.

   But here's where things get funky.  The RVI folder with the compile server only has a handful of files in it with no folders.  On the other working compile servers, the RVI folder is loaded with folders of support files.  It's like the installer isn't installing all the files right...

Copy RVI folder from working system on top of the half-installed folder; no change.  Blew away installation and start fresh with a new one to continue trouble shooting (this was done a lot)...

Do the various registry hacks to blow away leftovers from uninstall process and align with working compile server machines registries; no change.

Ran through the NI.com Knowledge Base and Forums.  Several related issues that either got resolved with reinstallations, left unanswered, or were resolved without clarification about what exactly went wrong or how to fix it.

Ran the TList hack manually (Fix TList.vi won't run unless you have the run-time for LabVIEW installed and my host Win7 OS does not); no change.

   Chased the Perflib fix rabbit down that hole; no change.

Next steps:

Will try to install from a different copy of the LVFPGA DVD in case my .iso image got fried or 'cleaned' by McAfee.

Any ideas?  I'd like to avoid reimaging the PC for a number of practical reasons, including not having the Win7 install DVD without invoking the wrath of IT, the paperwork/explanations associated with invoking IT, or the massive amount of time lost to that process (IT and the reimaging itself)...

[tkreider]

<Lame, can't edit my own message>

Trouble shooting (cont.)

Ping from VMWare and from other machines on the network passes.

I can open the NI.com website in the virtual machine and the host, so general network services are most likely not the issue.

Verified that other clients can't use the Win7 compile server either (it's not just the virtual machine that is having the connection issue).

[gsussman · Accepted solution]

I have seen some similar funny behavior when using a remote compile server when VMware gets thrown into the mix.

My specific case was:

WinXP (32 bit) host + compile server

WinXP (32 bit) guest + LV development system (bridged network operation)

Under some conditions (I never could figure out what the trigger was), the LV development system could not connect to the compile server. Restarting LV, and even the VM it was running in would not solve the issue. Moving the compile server to another physical machine did not solve the issue.

All firewalls were turned off with no change in behavior.

I ended up resorting to statically assigning the port that the remote compile server operates on via this KB:

http://digital.ni.com/public.nsf/allkb/BE02DC97330CD1D8862576A500015AB8

Once that was set, all of my LV development environments were set to use the static port. I have not seen the problem since. I think that there may be some issues with NI's Service Locator when dealing with VMware.

It does not sound like you are experiencing exactly the same issue but this may give you some other options to try.

[tkreider]

GSussman,

Wow, I can't believe that worked!  I had seen this topic in the past, but when I had similar issues on another machine that hack didn't do anything for me.  In this case, the compile server popped to life immediately from the VMWare session.

I set the port ID to 96 in both files and didn't even restart LV.  (I did restart the compile server though.)

Thanks for the tip.  I'm going to be scratching my head over what went wrong though.