Isso geralmente é causado pelo .Net Framework tentando verificar assinaturas em todos os assemblies que você está carregando. Microsoft várias KBs e blog posts sobre esse assunto, e a resposta curta é que você pode desativá-lo em machine.config
ou na% do aplicativoconfig
file:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
A resposta longa é bem explicada por shawnfa :
When the CLR loads an assembly which has an Authenticode signature, it will always try to verify that signature. This is in contrast to the Windows loader, which will verify the signature of a file only in specific instances, such as when the file is an ActiveX control. This verification can be quite time intensive, since it can require hitting the network several times to download up to date certificate revocation lists, and also to ensure that there is a full chain of valid certificates on the way to a trusted root. So, when an Authenticode signature is applied to an assembly it's not unheard of to see a several second delay while that assembly is being loaded.
Se você estiver em uma rede de acesso restrito, cada chamada ao ponto de distribuição da CRL terá que expirar, possivelmente colocando o atraso acima de 2 minutos.
Em termos de depuração, você normalmente pode solucionar esse tipo de interrupção, invadindo o código em um depurador e observando a pilha de chamadas. Algo tão simples quanto o Process Explorer deve ser capaz de carregar símbolos e mostrar que você está esperando em uma CRL.