Academic Company Events NI Developer Zone Support Solutions Products & Services Contact NI MyNI
19 ratings:
 4.57 out of 5     Rate this Document

Measurement Studio .NET Assemblies Take More Than 10 Seconds to Load at Run Time

Primary Software: Measurement Studio>>.NET Support
Primary Software Version: 7.0
Primary Software Fixed Version: 8.1
Secondary Software: Measurement Studio>>Standard Edition (Starter Kit)

Problem:
I am using the Measurement Studio .NET class libraries in my project and I notice it takes more than 10 seconds to load my application. If I remove the Measurement Studio assemblies from my project, then it loads quickly. What is happening and how can I fix this?

Solution:

Note Starting with Measurement Studio 8.1, Measurement Studio assemblies will no longer be authenticode-signed. The problem described in this KB will no longer be an issue if you are developing or deploying applications that use Measurement Studio 8.1 or later. If you still require authenticode-signed Measurement Studio assemblies, please contact Technical Support at National Instruments. Refer to the Technical Support and Professional Services topic in the NI Measurement Studio Help for information on contacting Technical Support.

This behavior occurs with any .NET 1.1 and 2.0 assembly that is authenticode-signed; it is not exclusive to Measurement Studio assemblies. Digital signing is also referred to as code signing. Code signing a .NET library is strongly recommended by Microsoft, and Measurement Studio signs all of our ActiveX and .NET components.

Code signing of assemblies makes components tamper-proof and ensures that you know the identity of the component publisher.

This problem occurrs because of the mechanism used by the .NET Common Language Runtime (CLR) to verify code-signed .NET assemblies. Part of the verification process requires an online look-up to check whether the certificate with which the assembly is signed has been revoked and is no longer valid. Windows does this by downloading a CRL (Certificate Revocation List). The first time a code-signed assembly is loaded by the .NET CLR, the CRL is downloaded from the certificate provider's server and cached on the system.

When the .NET CLR loads a code-signed assembly and is unable to reach the CRL distribution point, it records the failure as an inability to provide the assembly evidence that it was code-signed. So the assembly is allowed to load, but is not marked as being digitally signed. There is a 15 second delay for CRL retrievals. This is how long the CLR continues trying to download the CRL before it finally times out. So the delay in loading the .NET assembly occurs because Windows is unable to download the CRL and continues trying to download it for 15 seconds before timing out.

This behavior is by design.

The .NET CLR will not indicate any error or throw any security exception when verifying a signed assembly if the CRL distribution point cannot be reached. An error here from WinVerifyTrust(), the API used by the .NET CLR to verify a code signed assembly, prevents the assembly from being marked as code signed. Note that this does not apply to assemblies loaded through 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.

You can work around this issue either on a per-machine basis or on a per-application basis.

Per-Machine Workaround

To work around this issue on a per-machine basis, Microsoft recommends disabling CRL checking by changing a setting in Internet Explorer. Use the following steps to disable the CRL checking in Internet Explorer:

  1. Select Start » Control Panel.

  2. Double-click Internet Options.

  3. Select the Advanced tab.

  4. In the Security section, uncheck the Check for publisher's certificate revocation option.

By disabling the CRL checking using the Internet Options, you are not exposing yourself to a security threat because this check is not working. The reason why this problem occurs is because your network settings are not allowing Windows to access the CRL.

In addition, it is possible to programmatically set the CRL verification. When the Check for publisher's certificate revocation is unchecked, a setting in the registry is changed. To turn off CRL verification, set HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State  from 0x00023c00 to 0x00023e00. To turn CRL Checking on again, reset the State key to 0x00023c00.

Per-Application Workaround

To work around this issue on a per-application basis:

  1. Use .NET Framwork 2.0 SP1 or later or install a required Microsoft Hotfix.
  2. Create an application configuration file for each application you are applying the workaround to.
  3. Set the generatePublisherEvidence application configuration setting to False.
For more information on the generatePublisherEvidence application configuration setting, refer to Microsoft Knowledge Base 936707.

Related Links:

Attachments:





Report Date: 01/27/2005
Last Updated: 01/29/2008
Document ID: 3HQAOI5B

Your Feedback! poor Poor  |  Excellent excellent   Yes No
 Document Quality? 
 Answered Your Question? 
  1 2 3 4 5
Please Contact NI for all product and support inquiries.submit