Why are signed assemblies slow to load?

Question

I encountered a strange problem this week that I can't explain: I switched my application to use the signed version of some third party assemblies (Xceed Grid and some of their other components) and the application start time went into the toilet. Each time the application loaded a signed assembly, it took 30 seconds to load. Application start went from 5 seconds to over 90 seconds. What the heck is going on here?!

Some other info:

• This is a WinForms app running under .NET 3.5 SP1.
• The computer had no internet connection (on purpose, for security).

Bakelite

Did you change any settings for the runtime environment? Especially in which trust level do you execute the application? Default? – Carrollcarronade

How did you check the loading time ? – Dasya

In Internet Explorer go Options->Advanced. Uncheck the box "Check for publishers certificate revocation", that's helped me with similar situations in the past... – Welladvised

Answer 1

Have a look at these links:

• https://web.archive.org/web/20120812062059/http://blogs.technet.com/b/markrussinovich/archive/2009/05/26/3244913.aspx - The Case of the Slow Keynote Demo (Mark Russinovich’s Blog)

  Confident now that the cause of the startup delay was due to .NET seeing that Stockviewer.exe was signed and then checking to see if the signing certificate had been revoked, I entered Web searches looking for a way to make .NET to skip the check, since I knew that the keynote machines probably wouldn’t be connected to the Internet during the actual keynote. After a couple of minutes of reading through articles by others with similar experiences, I found this KB article ...

  ... checking of assembly digital signatures: create a configuration file in the executable’s directory with the same name as the executable except with “.config” appended

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
        <runtime>
                <generatePublisherEvidence enabled="false"/>
        </runtime>
  </configuration>
  

They might help. It could be that the config on your system means that the .NET framework is doing a lot of extra work to verify the assembly. If this is the case, then you can configure it to not be so picky.

• https://web.archive.org/web/20130409115103/http://blogs.msdn.com/b/tess/archive/2008/05/13/asp-net-hang-authenticode-signed-assemblies.aspx - ASP.NET Hang: Authenticode signed assemblies (If broken it is, fix it you should, by Tess Ferrandez, ASP.NET Escalation Engineer)

Holliman

Also, contact the author of the assembly in case they have other customer's who have reported the same issue. They may have an FAW section on their site or something. – Holliman

Thanks, that was exactly the problem! Heading over to post on the Xceed forums now so no one else has to suffer this same pain. – Bakelite

Answer 2

Jason Evans' post does contain the answer, but in the form of a link. I thought it would be good to post the actual solution here:

Create a file Appname.exe.config in the same folder as the executable (where Appname is the name of your executable; for development, this would be in the debug output folder). This shows an xml file that assumes you don't have other entries in the main config file; if you have the file already, I assume you would just add the new sections/text as necessary:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false" />
    </runtime>
</configuration>

Killen

Thanks Will. BTW, I see I should probably have posted my answer as a comment to Jason Evans' answer. I didn't mean to preempt his post. [Doh! What a newbie!] – Killen

Thanks for the answer! I still think the link is the definitive answer though because it contains the code, an explanation of the problem, and a thorough explanation of how to verify the problem. – Bakelite

Noting that this file is auto-generated in compilation from the App.config file. See also #2916523 and #13044030 – Gentlemanly

Answer 3

Just incase anyone else comes across this post, I've traced the issue a little further, because I was just trying to figure it out and found this page.

It appears that the CRL is checked each time you are running your process if the existing CRL that is on your machine has timed out, and not yet updated with a new one. You can test this by hitting the CRL at http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl and check the expiry date. Now configure a Proxy within IE that doesn't work. Set your machine date past the Expiry Date and retest your application.

If your NIC is disabled, the CRL is not checked.

If your NIC has no gateway, the CRL is not checked.

If you have a Proxy enabled and a gateway then the CRL is checked and if there is a problem with the Proxy, then you will experience this timeout.

If you connect to the internet successfully then the CRL updates and you will be fine for the time being.

My application was using some older Xceed Components in .NET 2.0 and has been working forever so it took a while to figure out what was going on.

Hydroscope

See also this answer on how to reset CRLs local cache on Windows: serverfault.com/a/318745/519078 (avoid messing with your computer's date) – Pallet

Answer 4

Loading signed assemblies will definitely be slower than non-signed counterparts because signature needs to be verified, but this should be completely negligible.

Passing from 5 seconds to 90 seconds?? I think you need to contact the assembly author and ask them if they changed only the signature :-)

Corpuz

The reason for 90 seconds is the test machine was not connected to the internet hence it was timing out. (This may sound like crazy talk, but there are some scenarios where this is quite valid.) – Bakelite

Answer 5

I would guess that you have the security settings set in a way so that the assemblies certificates get verified. So it likely tries to access the web to verify some certificate and then waits for a timeout (30 sec is a VERY typical timeout number).

You can verify this if you look at what happens in that 30 seconds. For my guess to be true there should be little CPU use and little HDD accesses in those 90 seconds. If you have high CPU use or bound by your HDD then it's something else.

BTW: Another option would be if your HDD is completely full and the assemblies are EXTREMELY fragmented (but 90 secs would be more than I ever heard of in that case).

Carrollcarronade

Answer 6

Try to start you application from visual studio with "Step over". This will start the code by stepping over each app, so you can check what takes so long. I once had this, and it turned out that my sql server was really messed up.

Another way to find out why it takes so long is to place breakpoint scattered through the loading code and see what the bottleneck is. If the application takes 90 seconds before it your first like, probably something with XCeed, or loading the signed assemblies.

Btw, im aware there are better ways to profile your application, but this quick 'n dirty way works quite nice and efficient to debug such problems

Bloodstained

Answer 7

Maybe the signed assemblies are not NGEN'd, while the unsigned ones are.

Section

Not sure but he is talking about 90!! seconds. Ngen is never going to have such a huge impact unless the assembly would be (literally) GBs in size. – Carrollcarronade