Strange delays in loading LabVIEW Vi that call .NET

[dannyt]

Hi,

 

I wanted to make this post in case it helps anybody else with the same problem, or to remind myself how-to fix it when I forget in a few months time.

 

I recently had the very embarrassing situation in front of my customer, a large EMS.I had just transferred a test solution that had been working for several months on my local site to a volume EMS, this transfer included the same PC and test fixture, the same software, written in LabVIEW 2012 and build into an executable. When I ran it up on the EMS’s site, some of my dynamically loaded VI would just hang for a time; the whole application would show not responding for a while and then it would suddenly spring into life and work OK and if loaded again they work fine with delay. But every time the executable was exited the same effect would occur.

 

It was not the sort of impact I was hopeing to make.

 

After some investigation I found out it only affected my VI’s that had calls to .NET components within them, I called NI support, who at that time could not suggest anything and in the end I had no option but the replace the .NET calls with other methods to achieve the same functionality.

 

So I created a very small stand alone executable with a single .NET call in it and found it worked on all my PC’s in my local factory but not on the PC’s in the EMS. All the PC’s were running the same .NET framework. As I had no idea what was going on and at that time NI support still did not have an answer to the problem I had no option but to stop using all .NET calls with all my software, I could not risk having a similar problem going forward.

 

Finally I realised that the one main difference between the PC’s was that my PC’s had direct access to the Internet, but the PC’s in the EMS were connected to a firewalled off Intranet. Following further conversations with NI support in the UK, with this new bit of information they came back with the following information.

 

 

“I have been speaking to my colleagues regarding this .net issue and one of them mentioned an interesting situation he came across before which might by chance apply to your pc. It seems that previously there has been an instance where the same behaviour of a .net call was taking a long time the first instance it was invoked. The reason for this turned out to be security built into the .net framework for particular calls. In some instances when particular .net calls are made it will want to verify the signature of the .net call to an online repository, if you have a PC that thinks it is connected to the internet it might be trying to do this and time out. Does this sound similar to what could be happening to your PC?”

 

 

and then a proposed solution followed

 

 

Part 1 changing the registry:
Change the registry parameter HKCUSoftwareMicrosoftWindowsCurrentVersionWinTrustTrust ProvidersSoftware PublishingState from 0x00023c00 to 0x00023e00

Part 2 changing the Group Policy:
Click Run > type gpedit.msc > Computer Configuration > Administrative Templates > System > Internet Communication Management >Internet Communication Settings, Under this setting Enable the "Turn Off Automatic Root Certificates Update" using the properties for this item.
Then on your command prompt, type gpupdate /force.

 

I have played around with this solution and it does solve my problems, I am not sure at this stage what the implication of these security changes are, but as the machine is not connected to the interent anyway I am not to worried.

 

So thanks NI for the support , I am now feeling happier about moving back to .NET solutions.

 

I hopefully this may help sombody out there.

 

 

 

[ShaunR]

 I am not sure at this stage what the implication of these security changes are, but as the machine is not connected to the interent anyway I am not to worried.

 

The NSA have to use other methods to tell you are connected

 

Good catch and thanks for sharing.

[mje]

Out of curiosity is this security behavior documented in whatever API you used?

[ShaunR]

Out of curiosity is this security behavior documented in whatever API you used?

 

It depends if they are authenticode-signed (apparently).

Edited March 25, 2014 by ShaunR

[LogMAN]

This issue is quite common. You might be interested in this article: http://digital.ni.com/public.nsf/allkb/7DC537BCD6E679C3862577D9007B799E

It describes two Workarounds, where the first one matches your solution. I preffer the second workaround, because it is easier to implement into the application itself (create if not exists).

[tnt]

Hi,

 

we had a similar problem as well, network connection: fast start, no network: very slow

--> see http://digital.ni.com/public.nsf/allkb/9A7E2F34EC9DDEDE86257A09002A9E14 (different article)
 

We used the workaround with the application configurationfile placed next to the executable (=same solution as LogMAN)

because it is a very easy fix, requires zero to less additional documentation in case of a reinstall

and does not need any changes to the Internet options (or regedit, or gpedit). 

(This apparantly resulted in an even faster startup of the application compared to altering the Internet options)

 

 

You can create an application configuration file:
 

1. Open Notepad and paste in the code below:
 

<?xml version="1.0" encoding="utf-8"?>

<configuration>

<runtime>

<generatePublisherEvidence enabled="false"/>

</runtime>

</configuration>

 

2. Save the file in the directory of the application with the name: <ApplicationName>.exe.config
 

3. Run the application, and the config file should disable the CLR check for the application.

Edited March 25, 2014 by tnt

[dannyt]

I was using the NetworkInterace and Process objects.

 

Shaun, I was feeling quite good about getting this solved, then you showed me I had just not search the web enough    , thanks for the link/s everybody

 

Now I have seen the application configuration file method to solve this I will have a play with that as I feel it is must better solution and gives me back full control and some practicability.

 

cheers all

 

Danny