Unexplained Network Access

Questions about GdPicture.NET license agreement.
Post Reply
masteriou
Posts: 8
Joined: Sat Mar 20, 2010 4:44 pm

Unexplained Network Access

Post by masteriou » Fri Aug 08, 2014 1:38 pm

Hi!

I tried to install my application on a customer's site and got the following behaviour:

In my application I call the following code:

Code: Select all

oLicMan.RegisterKEY <my GdPicture 8 License>
oLicMan.RegisterKEY <my GdPicture 9 License>
This both calls take about 100 ms on my development machine, on the customer's PC it takes about forever (39 seconds to be exact).
I used procmon.exe to check what's going on and there is a lot of access to the following adresses (logfile scan.xlsx in the attached zip)
a212-152-163-18.deploy.akamaitechnologies.com
ocsp.ams1.verisign.com
a23-54-101-163.deploy.static.akamaitechnologies.com

I discovered that the same accesses are happening (logfile regasm.xlsx in the attached zip) when registering GdPicture.NET.9.dll using the following command:

Code: Select all

RegAsm.exe GdPicture.NET.9.dll /codebase /tlb
If the startup time was so high only once it would be not so bad, but this happens everytime AND it happens everytime I use GdPicture to convert a file.

I tried to regasm some other .NET-DLL and there were NO network-accesses...

Can you please tell me, what's going on and how to change this? I have NO access to the internet on my customer's machine and I'm quite sure I will not get it just to be able to register the components...

GdPicture.NET.9
Windows 7/64

Best Regards
Michael Asteriou
Attachments
NetworkAccess.zip
ProcMon output for RegisterKey and RegAsm
(12.88 KiB) Downloaded 110 times

masteriou
Posts: 8
Joined: Sat Mar 20, 2010 4:44 pm

Re: Unexplained Network Access

Post by masteriou » Fri Aug 22, 2014 6:23 pm

Hi!

I just got an answer from the support staff (I've opened a ticket), this is the answer(in case anybody has the same experience)
This is simply the result of the .NET Framework online checking the validity of the certificate we use to digitally sign our products. It is the normal behavior of the .NET Framework when you want to register assemblies that are digitally signed.
We deliver the software components with digital signatures to make sure that the safety of the customer`s systems is maintained.
A standard Windows installation provides that during each start of digitally signed software the certificate that is used is checked for revocation (also see Wikipedia "certificate revocation list" = CRL).
We sign on the basis of a certificate by VeriSign, therefore Microsoft Windows tries to establish a connection (usually to crl.verisign.net but there are various mirrors) via various ports.
If it is not possible to establish this connection there will be serious performance losses in the starting phase of the program because the validation tool will wait for the timeout.
Bye
Michael

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests