11-22-2012 03:32 AM
Norbert,
Yes the boot up problem occurs on machines with runtime engine f2 onwards, according to that post you have linked for me upgrading to f3 should in thoery alleviate any issues with f2. However we still have the boot up issue.
I have tried to attach event logs but the post doesn't allow the event log file extension so please find them here:
https://skydrive.live.com/redir?resid=841530748CFE6204!374&authkey=!APvX9_IGbKQW3XU
The link contains the "Application" logs that occur for the period of boot up where we are presented with the Please Wait screen for approximately 20 minutes, let me know if this is of any use or if you want me to provide any other logs.
Regards,
Paul.
11-22-2012 03:57 AM
Paul,
the log you posted there does not contain errors. But i am not sure if you got the correct log. The Windows Event Log has several log types, so you have to dig a little in there and look for errors (exclamation mark in a red circle) and warnings (exclamation mark in yellow triangle).
Look for the services/process names failing or throwing warnings. My feeling is that you have at least a severe amount of timeout messages (expected as warning) during boot time.
You probably find this tutorial helpful.
Norbert
11-22-2012 04:49 AM - edited 11-22-2012 04:50 AM
You might also want to compare your issue with this thread.
12-13-2012 09:18 AM
Hi Paul,
Just seeing if you have had any more luck finding the source of this problem? After talking to a colleague he suggested disabling the “Network Store Interface Service” as we tried before, but highlighted that NSIS has several dependencies.
Try setting the following services to manual start-up: NSIS, DHCP Client, IP Helper, Network Connections, Network Local Awareness and Workstation.
Also as Norbert_B suggested could you post the “Operational “ Log, which is found in the Event Viewer under “Applications and Services Log”, “Microsoft”, “Windows” and “ Diagnostic-Performance”. Then we can go from there.
Regards
12-17-2012 05:06 AM
To OctrainePaul and MRH,
This issue has now been made aware to our R&D team for further examination. However we would like to speak with you directly, so we can work with you more closely on this issue.
If you could both call us on 01635523545 at NI UK, explaining that you have been asked to contact the technical support department specifically, then we can take things further from there.
Regards
12-17-2012 07:50 AM - edited 12-17-2012 07:52 AM
Hello All,
I have had the same problems after installing LV2012 on my Windows7 32bit- System. It took the System 18 minutes to log on to the domain. After reinstalling my workstation with Windows7 64bit, the problem showed up again after installing LV2012. Starting the computer without connected ethernet- cable showed normal startup behaviour.
The solution for me was to check my domain user profile, there I had a Base- path, wich didn't exist anymore. The setting was to link a Drive- letter to this path in the Domains network. To be exact, it was a path to a Distributed File System- Entry, which didn't exist anymore. In the Domain User Profile Properties Dialog this setting is to find in the Tab "Profile", as to be seen in the image.
After deleting this path and switching the radio-button back to the empty "Local Path" fixed my problem.
Hope, this helps,
12-17-2012 09:24 AM
Hi all,
we've the same problem with a Labview 2012 f3:
We make an Installer with no Web-Services and the installer installs the Ni mDNS Responder service (for Web Services)!
This means that the Ni mDNS Responder service is installed and 1 or 2 (64 bit) registry entries are done:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WinSock2\Parameters\NameSpace_Catalog5\Catalog_Entries\000000000005
which enables the mDNS Responder service
So if you disable this service and disable these registry entries, there is no problem.
Another way is to delete the binary "resonder.msi" file from the Installer build: Then there is an error message during Installer, but it works.
But these ar only ugly workarounds!!!
There is a service request open for me (Reference#1242360) in National Instruments, but with still no solution!
The main problem is the Resonder Service which searches for NI hardware using the Apple Bonjour Service.
Best regards
Johann
01-10-2013 08:08 AM
Hi all,
I just wanted to get an update on this issue. Are you still experiencing the slow boot times? Or have you managed to find a solution?
If you have found a solution then it would be great to know what steps you took to achieve this, as there are still people experiencing this same problem.
We are still working on a solution, as yet there hasn’t been a single fix but the steps suggested by daveTW and johannseehauser have worked for some cases. If you can carry out the following steps, it will help us find a route cause of the problem.
Thanks for your help working towards a solution.
08-07-2013 11:45 AM
Reviving an old thread to add info for anyone else who may have this problem...
I have the same symptoms described with the slow boot up & "Please Wait" message on a dev laptop I use. I did a quick data acq program for a co-worker with an installer last week when this problem popped up. We run LV 2010 here. The installer was calling for the Device Driver disc labeled Feb 2013, found the disc and finished the installer. Once installed on the target pc the bootup problem started. After various debugging without success I un-installed everything and started over. I found that by installing the RTE, my app, GPIB drivers and then the device drivers from the August 2010 disc the problem did not come back.
On a another though... I am also having trouble deploying a TestStand sequence that contains the LV Report class object, thinking that maybe this could also be part of that problem. Planning on un-installing LV on my dev laptop & reinstalling from the 2010 discs only and then trying to deploy the TS sequence. If that solves my problem I will update the other thread in the TS forum with this info...
10-30-2013 02:14 AM
Does anybody know if this problem still occurs with LabVIEW 2013?
I can't find any up-to-date information about this issue.
Thanks,
Michael