CryptoAPI cryptographic service provider (CSP) for this implementa

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a multithreaded server application where each thread
instantiates and uses the RSACryptoServiceProvider class when needed. During
testing there can be as many as 100 threads attempting to instantiate
RSACryptoServiceProvider simultaneously. When this happens, most of the
time, but not always about 3 of the threads throw the following exception
while attempting RSACryptoServiceProvider instantiation.

"CryptoAPI cryptographic service provider (CSP) for this implementation
could not be acquired."

Is the underlying CryptoAPI not threadsafe? Or can it just not handle too
many instantiations in close succession, perhaps because of not being able to
cleanup its resources fast enough.

Should I mark code that uses RSACryptoServiceProvider as a critical section
by using lock statements?

NOTE: When my application has been released to production there could be as
many as 500-1000 close succession instantiations of RSACryptoServiceProvider.

I also saw a post that appeared to have a similar problem on 10/25/2004 by
Don Nelson in dotnet.framework.aspnet.security
 
Chris Tanger said:
I have a multithreaded server application where each thread
instantiates and uses the RSACryptoServiceProvider class when needed. During
testing there can be as many as 100 threads attempting to instantiate
RSACryptoServiceProvider simultaneously. When this happens, most of the
time, but not always about 3 of the threads throw the following exception
while attempting RSACryptoServiceProvider instantiation.

"CryptoAPI cryptographic service provider (CSP) for this implementation
could not be acquired."

Is the underlying CryptoAPI not threadsafe? Or can it just not handle too
many instantiations in close succession, perhaps because of not being able to
cleanup its resources fast enough.

Should I mark code that uses RSACryptoServiceProvider as a critical section
by using lock statements?

NOTE: When my application has been released to production there could be as
many as 500-1000 close succession instantiations of RSACryptoServiceProvider.

I also saw a post that appeared to have a similar problem on 10/25/2004 by
Don Nelson in dotnet.framework.aspnet.security
Click to expand...

I've heard about similar problems involving creating and opening SQL
connections. It could be that instantiation isn't properly threadsafe -
I'd imagine that once created, so long as you only used each instance
within one thread, you'd be okay. It's worth trying a lock just around
instantiation (make a factory for it to make it easier).
 
Thanks Jon, I'll try it and let everyone know how it works out. It may
be difficult to determine if this has truly solved the issue though as
locking may slow things down enough to make it work anyway.
 
Not sure if this would be good for you or just ugly, but maybe cache up a
few hundred in an collection class and hand them out to handle peak load
times. Would then need to mess with some watermark level to refill the
pool. Not sure.
 
Sometimes I get the following error while attempting to do "New
RSACryptoServiceProvider":
The RPC server is too busy to complete this operation.
 
I think this will be a bit ugly, but I believe I will be required to
do as you have suggested. Half of the problems is that there is no way of
constructing an RSACryptoServiceProvider without generating a key. They
should have provided a constructor that could be passed pre-existing
RSAParameters.
 
Initial testing shows that putting locks around the constructor of
RSACryptoServiceProvider actually seems to improve performance by 30%! And
it seems to be solving the issue so far.
 
Putting a lock statement around the RSACryptoServiceProvider constructor
not only appears to fix the problem but seems to improves performance by
about 30%.
 
Back
Top