labview runtime - slow pc start up

[rrawer]

Hi Nottilie,

Thanks for the input. I had one machine where the workarround with disabling the additional options in teh setup did not work. I also disables all NI services on that machine and had still 20 minutes before I coudl enter the password.

Then I applied the Registry patch and it no starts smoothly in less then 30 seconds 🙂
(remeber: the catalog entry can be different to 000000000005 - so check all entries for which one is referring to nimdnsNSP.dll...)

Rainer

[Maqsood]

Hi,

just to let you know:

I tried a cabled connection (instead of wifi) and my laptop started up fine, went back to wifi and the probelm returned ~20min start up!

Furthermore, the delay only happens here at my office (this is where the server is), but at home (oe elsewhere) my same taptop starts up fine WITH wifi on!

But the problem is not soley wifi - because if i uninstall NI runtime - then all is fine here at office with no start up delay?

regards

Max

[Maqsood]

Hi Nottilie,

Got our IT people to try your fix:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WinSock2\Parameters\NameSpace_Catalog5\Catalog_Entries\000000000006
contains the Word "Enabled".  alue set at 0 (amended from 1).

and laptop starts up in less than a minute. So after 2 months of slow start up, all is now sorted. Thanks.

regards

Max

[Eden_S]

Hi everyone,

Thank you for all of the information you have been providing. As this issue seems to be affecting a relatively high number of people, it has been given priority by R&D who would of course like to see this solved as soon as possible.

As such, it would be a great help to us and to you if you could call our technical support branch to give us information regarding your system. You can contact UK Support on 01635 523545 or if you are not from the UK you can find your local branch number by heading to ni.com and clicking 'contact' in the top right of the screen. I would like to note that the UK office closes for Christmas midday on Monday 24th.

If you don't have a support service please mention what the call is regarding and you shall be passed through to an engineer. This will speed up the process of passing on information to R&D and therefore will help us fix this issue sooner. Again, thank you all for the information and for your continued patience.

Best regards,

[Jeff-P]

Hello everyone,

Thank you to everyone for posting the workarounds that you have found so far. We are aware of this issue and are working to determine the root cause of the behavior. It is being tracked under CAR 383246. We greatly appreciate your assistance in troubleshooting this issue as it has been difficult to characterize. All, but one person, have been able to get around the long boot times by using the registry workaround described below. We recognize that this is only a temporary workaround rather than a fix. We have unfortunately not been able to replicate this issue within R&D as it seems to be network specific.

To summarize the issue - After installing the LabVIEW 2012 Runtime Engine (RTE) on Windows 7 PCs on certain networks, those PCs take significantly longer to boot. If the RTE is uninstalled, the boot time returns to normal.

There have been a number of workarounds posted. The workaround we recommend is to disable the NI mDNS Responder Service through services.msc and then modify the following registry key (Change Enabled to 0)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WinSock2\Parameters\NameSpace_Catalog5\Catalog_Entries\000000000005

Note: Do not just pick 000000000005, click on each catalog entry until you find the one whose DisplayString is mdnsNSP and set that one's Enabled to 0. For 64-bit Windows, you may have an additional key under Catalog_Entries64 which should also be set to 0.

A second workaround was to install the RTE without selecting anything else in the installation window (see image below). I am interested to hear if this fixes the long boot times for those of you who can recreate this.

We need some detailed boot logs of a regular boot and slow boot to help determine the root cause of the long boot times so we can analyzer the differences. This link is a guide to create a Process Monitor log (.pml) in the section called Step-by-Step: Finding CPU Hogs. If you are able to generate those logs, please private message me (click on my name to the left of this post to view my profile, then click "Send this user a private message" in the Contact Section) to arrange the transfer. We greatly appreciate your assistance troubleshooting this issue.

Best Regards,

Jeff Peacock 

[PhysicsGuy]

I just installed the nidaqmx 9.6.1 driver on a 64 bit windows 7 machine and am seeing the same 15-20 minute startup time.  Do you want to mix the nidaqmx stuff in with labview or should it go in another group?

Tom

[rrawer]

Some more interetsing things...

We just upgraded from the original MS SBS 2003 domain to SBS2011 (which is in fact Server 2008 R2 based).

With the old SBS2003 domain We only had the problem on Windows 7 PCs where we isntalled the standard LV2012 runtime library. On the development machines where LV 2012 Full Development system (32bit ond e Win 7 64 bit machine) was installed the problem did not ocure. However after upgrading to the SBS 2011 domain also the two development system showed the problem which was solved by modification of the known registry keys...

[Tesla1977]

Same thing here.

Laptops of different make (Lenovo T520, T530, Panasonic) have this problem, but only after upgrading drivers that bring a new MAX version (like X-Net, DAQmx...)

We dont have LV2012 installed.

With MAX 5.1 everything is fine, with MAX 5.3.1 and upwards we have this problem when booting a PC with wifi. When LAN cable is connected, boot times are normal.

[Tesla1977]

Update:

Workaround with registry edit worked for us, although in catalog_entries we had to disable the entry whose DisplayString is "NI mdnsNSP" and NOT the one named "mdnsNSP".

[Luke_W]

You should be able to use the nimdnsNSPTool.exe in a command prompt to remove this service. The exe ships with mDNS responder and can be used with the following command:

NSPTool -remove "981DF75B-898E-4c0c-B01C-5F181F817889"

Note that the guid that is being passed in as an argument should match the default ProviderId in the registry. This above example corresponds to a ProviderId of 5b f7 1d 98 8e 89 0c 4c b0 1c 5f 18 1f 81 78 89 (you should be able to shuffle around the bytes/Endian and see the similarity). If the ProviderId is already taken by another service, Windows may assign a different unique ProviderId and the command line argument will need to be changed. If you suspect this may be the case (running the tool doesn't resolve the issue), check this registry value, located in the same location as mentioned earlier in the thread, and see if the ProviderId disagrees.

-Luke