tags:

views:

449

answers:

5

I've built a .NET console application which worked fine for several years. Since November 23, it takes a huge amount of time to start (15 seconds) when run in production (it works fine when run from Visual Studio).

I've tried to trace back what is going on with Process Monitor (ProcMon) and I've found this pattern:

  • App starts normally
  • App loads cryptnet.dll
  • App goes to sleep and I see a series of TCP Reconnect messages where the machine tries to reach 206.53.176.17 through HTTP (which seems to be in Bermuda).
  • App queries info on cryptnet.dll
  • App tries to connect to 206.53.176.78 through HTTP.

After 15 seconds, everything starts working again (I see an access to crypt32.dll as the first thing happening the the application continues its loading).

I am completely lost: the problem is not related only to my machine, but all colleagues how are using my tool experience the same issue. This seems to have something to do with Authenticode signature verfications done while the app is being loaded.

Indeed, when trying to view the Digital Signatures of the EXE through the Explorer, clicking on Details takes 15 seconds to view the "Digital Signature Details" panel (without any error). The issuer of the certificate is defined as:

CN = QV Schweiz ICA
OU = Issuing Certificate Authority
O = QuoVadis Trustlink Schweiz AG
C = CH

and it is still valid (message says "This digital signature is OK.").

Note: The root issuer of the certificate is http://www.quovadisglobal.bm/ which happens to be in Bermuda...

+1  A: 

If you claim this is a new behavior, I'd check the machine for spyware/malware/rootkits. As an immediate solution, block this address in your firewall and hosts file.

Traveling Tech Guy
On a clean install I see exactly the same behaviour. See my edit about the fact that the 15 seconds delay also applies when trying to view the digital signature details of the EXE.
Pierre
Could it be that your installer app is compromised and is the way-in for the virus? Try building a new installer for your console app and try that on a new, clean PC build.
Neil Barnwell
You're making the case for a rootkit. It's a type of malware that replaces a legitimate part of the OS (such as your DLL) with a virulent version. Read more here: http://en.wikipedia.org/wiki/Rootkit. And download this tool to check your system: http://technet.microsoft.com/en-us/sysinternals/bb897445.aspx (although there may be newer versions by now). BTW, copying/installing the same app and/or OS will just pass the rootkit to the next system.
Traveling Tech Guy
Finally this was no virus... but an issue with the certification authority whose servers were unreachable from our point of the globe.
Pierre
I had no idea there were cert servers in Bermuda :) Still a firewall block ought to do it.
Traveling Tech Guy
A: 

This sounds like a virus. I Googled cryptnet.dll, and found that it's a system file. If your app isn't directly referencing it, then the chances are it's being accessed via several layers of abstraction (i.e. via the .NET framework) and is corrupt or has a virus. If it's accessing a server in Bermuda, it's almost certainly a virus.

Could it be that your installer app is compromised and is the way-in for the virus? Try building a new installer for your console app and try that on a new, clean PC build.

You could try replacing the cryptnet.dll file with a fresh one, as described by one answerer here: http://www.techimo.com/forum/technical-support/93583-what-hell-cryptnet-dll.html

if you are seeing that error...you need to replace the cryptnet.dll file. if you installed SP1 there should be one under the servicepackfiles\i386 folder

fyi, cryptnet.dll is used for SSL which is a protocol used when accessing https: sites.

Neil Barnwell
A: 

Does this help? It seems similar.

RCIX
+3  A: 

The checking of the digital signature on your assembly (Authenticode) is probably what is causing the delay.

Excerpt from this MSDN article:

Authenticode verification adds to the startup time. Authenticode-signed assemblies have to be verified with the certification authority (CA). This verification can be time consuming, because it can require connecting to the network several times to download current certificate revocation lists. It also makes sure that there is a full chain of valid certificates on the path to a trusted root. This can translate to several seconds of delay while the assembly is being loaded.

DSO
or, as i posted first, http://blogs.technet.com/markrussinovich/archive/2009/05/26/3244913.aspx
RCIX
A: 

See this post on StackOverflow for the solution:

http://stackoverflow.com/questions/1618596?sort=newest#sort-top

MartinKB