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

Chris Tanger <(E-Mail Removed)> wrote:
> 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

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

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

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.

"Jon Skeet [C# MVP]" wrote:

> Chris Tanger <(E-Mail Removed)> wrote:
> > 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
>
> 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).
>
> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too
>

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.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Chris Tanger" <(E-Mail Removed)> wrote in message
news:4F5284C5-DFF8-4019-89E5-(E-Mail Removed)...
> 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.
>
> "Jon Skeet [C# MVP]" wrote:
>
> > Chris Tanger <(E-Mail Removed)> wrote:
> > > 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
> >
> > 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).
> >
> > --
> > Jon Skeet - <(E-Mail Removed)>
> > http://www.pobox.com/~skeet
> > If replying to the group, please do not mail me too
> >

Sometimes I get the following error while attempting to do "New
RSACryptoServiceProvider":
The RPC server is too busy to complete this operation.

"Chris Tanger" wrote:

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

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.

"William Stacey [MVP]" wrote:

> 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.
>
> --
> William Stacey, MVP
> http://mvp.support.microsoft.com
>
> "Chris Tanger" <(E-Mail Removed)> wrote in message
> news:4F5284C5-DFF8-4019-89E5-(E-Mail Removed)...
> > 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.
> >
> > "Jon Skeet [C# MVP]" wrote:
> >
> > > Chris Tanger <(E-Mail Removed)> wrote:
> > > > 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
> > >
> > > 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).
> > >
> > > --
> > > Jon Skeet - <(E-Mail Removed)>
> > > http://www.pobox.com/~skeet
> > > If replying to the group, please do not mail me too
> > >
>
>

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.

"Chris Tanger" wrote:

> 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.
>
> "Jon Skeet [C# MVP]" wrote:
>
> > Chris Tanger <(E-Mail Removed)> wrote:
> > > 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
> >
> > 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).
> >
> > --
> > Jon Skeet - <(E-Mail Removed)>
> > http://www.pobox.com/~skeet
> > If replying to the group, please do not mail me too
> >

Putting a lock statement around the RSACryptoServiceProvider constructor
not only appears to fix the problem but seems to improves performance by
about 30%.

"Chris Tanger" wrote:

> 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.
>
> "Jon Skeet [C# MVP]" wrote:
>
> > Chris Tanger <(E-Mail Removed)> wrote:
> > > 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
> >
> > 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).
> >
> > --
> > Jon Skeet - <(E-Mail Removed)>
> > http://www.pobox.com/~skeet
> > If replying to the group, please do not mail me too
> >