Measurement Studio for .NET Languages

Showing results for 
Search instead for 
Did you mean: 

(MS .NET, Csharp) adding component causes severe slowdown.

@Chris Williamson wrote:
Hi Bilal,

Thanks for your help with this.

I've just checked my internet settings and both of the certificates that you mentioned are already installed on my pc. Zax has tried re-importing them, but it didn't help.

You are welcome to contact me directly about this issue.


Chris Williamson

Please keep the rest of us who are experiencing the same problem up to date on the progress of the solution.
0 Kudos
Message 21 of 31

We have contacted Microsoft about this issue and it seems that they are aware of this problem. The issue arises because the .NET Common Language Runtime (CLR) uses the Public Key Infrastructure (PKI) system found on Windows systems and on an isolated network, the certificate checking mechanism times out after a certain number of attempts to servers that host the Certificate Revocation List (CRL). The .NET CLR loads the assembly after all the re-tries are completed, which shows up as a 10+ second delay. The timeout and re-try settings are not user configurable, from what Microsoft told us.

This problem would occur with any .NET assemblies that are code signed with a digital certificate. Code signing assemblies is recommended by Microsoft since doing so makes components tamper-proof and ensures users know the identity of the component publisher.

The workaround they presented was to disable Certificate Revocation checking by setting this option in Internet Explorer.

1. Launch Internet Explorer and go to Internet Options

2. Clicking on the Advanced tab

3. Scrolling down to the "Check for publisher's certificate revocation" checkbox.

We realize this is not the ideal solution. However, you are seeing the slow loading times for digitally signed assemblies because your networks are preventing the crl check from occuring anyway. By turning this option off, you are preventing the check from occuring in the first place. We are continuing to pursue this issue with Microsoft until this can present us with a feasible workaround for this.
Bilal Durrani
0 Kudos
Message 22 of 31
Sorry, meant to say until Microsoft can provide us with a feasible solution.
Bilal Durrani
0 Kudos
Message 23 of 31
The following is a transcript of a chat I had with Thawte technical support, which may be of some relevance:


Chris Williamson

Transcript follows:

Ivan : Hello! Welcome to the real-time technical support centre at Thawte. My name is Ivan, how can I help you?

Chris Williamson : Hi Ivan. We are having problems using a signed component produced by National Instruments, but signed by Thawte
Chris Williamson : The componenet takes approx 16 seconds to load. It appears to get stuck on network access.
Chris Williamson : It seems to be checking the Thawte certificate (which is odd since the program loads from the local hard drive)
Chris Williamson : I'm trying to find out - "Why does the certificate need to be checked", when the program is loaded from the local file system and "Why does checking take 16 seconds"
Chris Williamson : The component is a .NET assembly
Ivan : The certificate contains a extension that connects to our server to check the certificates validity.
Ivan : Its part of the security. To see if the certificate has been revoked or not.
Chris Williamson : WHy would this check timeout? Could it be connected to our firewall?
Ivan : Our bandwith provider has had a major bandwith dropout as two of their 3 international lines have crashed.
Ivan : That has caused bandwith problems accross all our servers and networks.
Ivan : We are hoping they will still fix this today but this is probably why it is taking so long on your side to validate the certificate.
Chris Williamson : Hmm - the 16 second load time makes the component unusable. Why does the certificate need to be checked when loading from the local hard drive.
Chris Williamson : I could understand the need to check the certificate for components from the internet.
Ivan : Anytime the certificate is accessed if you are connected to the net the local security system will try and verify the validity of the certificate. If you are not on the net it should not. Do you have a machine that is not on the net that you could try and run this on to see if the same thing happens?
Chris Williamson : We've already checked. The component loads instantly if I pull the network cable out of the back of my PC
Ivan : Then we know. I seriously think this is only happening now because of the international backbone of our ISP having crashed. They should have this resolved soon at which point everything will speed up again.
Chris Williamson : How soon? And will it happen again? I don't want to ship our software and then in six months time be overwhelemed by technical support calls when this problem re-occurs
Ivan : This is the first time it has happened in the 4 yrs that I have been here. I can't say when it will be up for sure and I can't say if it will happen again as its not us, if the Network backbone provider SAIX.
Ivan : They know this is urgent and are working on this high priority.
Chris Williamson : Ok - thanks for your help
Ivan : You're welcome.

0 Kudos
Message 24 of 31
Hello all.

After talking to Microsoft about this behavior, they were able to provide me with more information about the behavior we are seeing. Thawte has no control over this behavior, so you will probably continue to see the problem, even after their ISP backbone issue is corrected. Unless ofcourse you use the workaround. Read on for more information about that.

Internally, the .NET framework is using the WinTrust() APIs to verify a digitally signed assembly. Part of this validation requires downloading the CRL (certificate revocation list) from the Certificate provider (Thawte). When the CLR (Common Language Runtime) loads an Authenticode signed assembly and is unable to reach the CLR distribution point, it records the failure as an inability to provide the assembly evidence that it was Authenticode signed. So the assembly is allowed to load, but is not marked as being digitally-signed.

This behavior is by design.

The delay occurs because of the behavior of the WinTrust() APIs .The timeout for CRL retrievals is 15 seconds. The timeout settings for this API is not user configurable.

The CLR will not indicate any error nor throw any security exception when verifying a signed assembly if the CRL distribution point cannot be reached. An error here from WinVerifyTrust() just prevents the assembly from being marked as Authenticode-signed. (Note that this does not apply to assemblies loaded thru the Internet Explorer hosting interface).

You could manually download the CRL, and install it on your system. But the CRL is valid only for 10-15 days, so unless your system is able to update the file after this time, you will run into the same problem again.

Microsoft recommended the same workaround that has been described previously.
The workaround they presented was to disable Certificate Revocation checking by disabling this option in Internet Explorer.

1. Launch Internet Explorer and go to Internet Options
2. Click on the Advanced tab
3. Scroll down to the "Check for publisher's certificate revocation" checkbox and uncheck it.

By disabling the CRL checking using the IE options, you are not exposing yourself to a security threat because this check is not working for you in the first place. The reason why this problem is showing up is because your network settings are not allowing the Windows Public Key Infrastructure (PKI) system to access the CRL.

I’ll document this information on our website to make it easier to find.

Hope this explains things.
Bilal Durrani
0 Kudos
Message 25 of 31
any updates on this issue, or is it still best to use the workaround?
0 Kudos
Message 26 of 31
Hello everybody! I've encountered the same problem with assembly loading, and the recommended solution (i.e. MANUALLY turning off the certificate revocation check) seems to be a perversion. I think that we must ask a Windows/Dotnet guru like Jeff Richter how to cut off this annoying certificate from an .net assembly. 🙂
0 Kudos
Message 27 of 31
Heh. I've found a workaround for this notorious trouble. You can automate turning off the certificate revocation check, by changing registry value
"HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State"  from 0x00023c00 to 0x00023e00. This "elegant" trick will  solve the problem!!!

In fact, this operation does the same as clicking the check-box in IE options, mentioned above. But end-users shouldn't adjust the IE settings manually, imho, it'd be easy to write application-loader, that changes registry value, runs the main application, and after that changes this registry value to its initial state.

registry monitoring rocks!
0 Kudos
Message 28 of 31

Thanks for sharing this with the forum.

I would also recommend providing this feedback to Microsoft so you would'nt run into these issues in the first place.

Bilal Durrani
0 Kudos
Message 29 of 31
This behavior is totally unacceptable.  NI needs to offer a way of loading the component without the signature for applications that aren't using the web.  Looks like you are turning your back on your primary market of lab instrumentation users.  Please email me the updated version when its ready.
VP Engineering
Uson LP
Houston, TX
0 Kudos
Message 30 of 31