Showing results for 
Search instead for 
Did you mean: 

"Error Cluster from Error" always being search in NI paths at load/run time

Hi Experts,


Please advise what seems to be the issue in this "Error Cluster From Error", see snapshots attached. It always flag to be searched in NI paths but successfully proceeded after, this just means slower execution to me when I see it's searching while other vi's in my large project are not . This happens in Labview 2014 patch f11(Windows-10) only, at the same LabView 2014 Windows-7 is just good. I suspect it's just the computer RAM which is only 8 GB, pls see my computer specs below. I plan to increase it but would like to know ahead first if there's any other known tweaks to do to fix or get rid of that visible window searching pop-ups, this means faster execution. Please share. Thank you.


Computer specs:

DELL Optiplex 7070 ( Windows 10 )

Intel (R) Core (TM) i5-9600 (6 Cores/9MB/6T/3.1GHz to 4.6GHz/65W);
1 8GB 2X4GB 2666MHz DDR4 Memory




0 Kudos
Message 1 of 8

Why don't you attach CONFIGURE, as this seems to be where the error is occurring ...  maybe we can better understand what is happening here.  What happens if you load just this VI by itself -- does it still take a long time to find things?


Bob Schor

0 Kudos
Message 2 of 8

Thank you Bob, appreciate your fast reply. Unfortunately that user vi is just one of the many i see, i did not go in that way of expressing my questions due to i might need to attach a lot of vi’s from my large project which i just  inherited from the team. Any other isolations approach is of course very much appreciated. But if really needed, let me know, i’ll settle things, just that it might get delay as it’s already 2:30am in my region(Singapore). Thanks again.



0 Kudos
Message 3 of 8

Hi Bob/All,


Am sharing an exact loading scenario of the issue I have, I did a PC screen capture from start to successful end of the loading, here it's showing how the searching details looks like. Please see if you have any similar experience or any thing for me to do to isolate effectively the problem, I tried opening many of the affected vi's shown but I cannot see commonality yet. Any tools or any Labview settings to help me identify what exactly my problem here? Please click the link below for the short video clip of the actual loading and initializations of my program fyr. Thank you.

0 Kudos
Message 4 of 8

Who is going to click on a shortened link?  Not me.

(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 8

Hi Bill,


Anyone who would like to share solutions or advices is of course welcome to click and see the link, I hope you are able to see it. Thanks.




0 Kudos
Message 6 of 8

We are not the ones asking for help.  If you want help, at least two of us have said you need to provide us (by attaching them) VIs that are causing you trouble, along with enough additional information (such as data they may require) to demonstrate the issue.


You have to "do the work" of providing us your data and clarifying your problem.


Bob Schor

0 Kudos
Message 7 of 8

Oh ok Bob, am sorry for that. As I've said the many affected vi's are scattered within the project and has a lot of dependencies across. It's quite a large library of fiber optic instruments calls/interfaces. I was just thinking other approaches besides drilling vi's. That's why I work on capturing and sharing in video clip which are the NI paths being search for certain vi's flagged, hoping there could be a good hint or similar experience from this community. Unfortunate that I cannot immediately share company propriety SW. I'll just try other things first and will ask some of my seniors if I can share those affected vi's, then I'll just repost again.  Thank you for your time Bob. 

0 Kudos
Message 8 of 8