The
scriptsn*.dll module is functioning correctly; there is nothing to detect or do differently.
The most direct solution is to revise the implementation of these components to impose a consistent lock-acquisition ordering. Either
JScript9.dll should avoid the callout to
CryptAcquireContext from within its
DllMain, or
cryptsp.dll should avoid calling
LoadLibrary while
CryptAcquireContext holds a critical section.
The author of the affected application could revise the overall program flow so the activity in these thread stacks does not occur concurrently (or at all). Pre-loading the affected libraries (
JScript9.dll or
rsaenh.dll) or delaying the activity that goes through
SCRIPTSN,
OLE32,
JSPROXY, or
WININET could also resolve the issue.
The developer of
jscript9.dll can also resolve the issue by removing the callout to
CryptAcquireContext from their
DllMain, which violates a basic principle defined by Microsoft. For details see:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).aspx
Although
DllMain can create synchronization objects, it must
not try any serializing operations on them because this attempt can cause deadlocks.
