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).

Did you change any settings for the runtime environment? Especially in which trust level do you execute the application? Default? — Foxfire, Oct 24 '09 at 17:47
In Internet Explorer go Options->Advanced. Uncheck the box "Check for publishers certificate revocation", that's helped me with similar situations in the past... — ParmesanCodice, Oct 24 '09 at 18:19

score 18 · Answer 1 · edited Jun 16 '15 at 16:21

18

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>

edited Jun 16 '15 at 16:21

dcharles

4,822
2
32
29

answered Jan 13 '10 at 19:03

MartinKB

243
2
6

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!] – MartinKB Jan 13 '10 at 19:43
1

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. – Mike Post Jan 15 '10 at 00:12

score 16 · Accepted Answer · edited Apr 28 '22 at 15:23

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)

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. — Jason Evans, Oct 24 '09 at 17:51
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. — Mike Post, Oct 28 '09 at 02:44

score 7 · Answer 3 · answered Sep 13 '11 at 03:48

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.

See also this answer on how to reset CRLs local cache on Windows: https://serverfault.com/a/318745/519078 (avoid messing with your computer's date) — Indigo, Aug 10 '22 at 15:49

score 1 · Answer 4 · answered Oct 24 '09 at 17:47

1

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 :-)

answered Oct 24 '09 at 17:47

Darin Dimitrov

1,023,142
271
3,287
2,928

2

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.) – Mike Post Sep 13 '11 at 04:21

score 1 · Answer 5 · answered Oct 24 '09 at 17:55

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).

score 1 · Answer 6 · answered Oct 24 '09 at 18:22

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

score 0 · Answer 7 · answered Oct 24 '09 at 17:48

0

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

answered Oct 24 '09 at 17:48

leppie

115,091
17
196
297

1

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. – Foxfire Oct 24 '09 at 17:50

Why are signed assemblies slow to load?

7 Answers7

Linked