Hi,
Using React.NET 3.0.1 which uses ClearScript.V8 5.4.8 following hang is observed on recycling application pool
```
.NET Call Stack
.SharedPtr.Release(SharedPtr*)+d7
[[InlinedCallFrame] (.Decrement)] .RefCount.Decrement(RefCount*)
Microsoft.ClearScript.V8.V8ContextProxyImpl.!V8ContextProxyImpl()+4e
Microsoft.ClearScript.V8.V8ContextProxyImpl.Dispose(Boolean)+1f
[[DebuggerU2MCatchHandlerFrame]]
[[ContextTransitionFrame]]
[[GCFrame]]
[[DebuggerU2MCatchHandlerFrame]]
Full Call Stack
ntdll!NtWaitForSingleObject+14
KERNELBASE!WaitForSingleObjectEx+8f
v8_x64!v8::Extension::dependencies+329ac
v8_x64!v8::ExternalResourceVisitor::VisitExternalString+28187
v8_x64!v8::ExternalResourceVisitor::VisitExternalString+1a3
v8_x64!v8::ExternalResourceVisitor::VisitExternalString+533b
ClearScriptV8_64+14216
ClearScriptV8_64+120e4
ClearScriptV8_64+13e3f
ClearScriptV8_64+50a8
<Module>.SharedPtr<V8Context>.Release(SharedPtr<V8Context>*)+d7
[[InlinedCallFrame] (<Module>.Decrement)] <Module>.RefCount.Decrement(RefCount*)
Microsoft.ClearScript.V8.V8ContextProxyImpl.!V8ContextProxyImpl()+4e
Microsoft.ClearScript.V8.V8ContextProxyImpl.Dispose(Boolean)+1f
clr!FastCallFinalizeWorker+6
clr!ETW::GCLog::SendFinalizeObjectEvent+c9
clr!MethodTable::CallFinalizer+b5
clr!CallFinalizer+5e
clr!FinalizerThread::DoOneFinalization+95
clr!FinalizerThread::FinalizeAllObjects+133
clr!FinalizerThread::FinalizeAllObjects_Wrapper+18
clr!Frame::Push+59
clr!PEDecoder::GetNativeCodeManagerTable+170
clr!PEDecoder::GetNativeCodeManagerTable+99
[[DebuggerU2MCatchHandlerFrame]]
clr!Thread::ShouldChangeAbortToUnload+45
clr!Thread::DoADCallBack+109
[[ContextTransitionFrame]]
clr!Frame::Push+a2
clr!FinalizerThread::DoOneFinalization+1f9
[[GCFrame]]
clr!FinalizerThread::FinalizeAllObjects+133
clr!FinalizerThread::FinalizerThreadWorker+bb
clr!Frame::Push+59
clr!PEDecoder::GetNativeCodeManagerTable+170
clr!PEDecoder::GetNativeCodeManagerTable+99
[[DebuggerU2MCatchHandlerFrame]]
clr!FinalizerThread::FinalizerThreadStart+10a
clr!Thread::intermediateThreadProc+86
kernel32!BaseThreadInitThunk+14
ntdll!RtlUserThreadStart+21
```
Comments: An access violation inside native V8 initialization nearly always indicates an out-of-memory condition. When it fails to allocate resources, V8 immediately crashes the process by raising an access violation. At startup, a V8 runtime tries to acquire large amounts of memory and address space to be handed off to its internal resource manager. Any allocation failure leads to an immediate crash. Does your crash always happen _after_ a recycle? Or can it happen randomly at any time? Other questions: Does your application run in a 32-bit process? Is it possible that it creates a large number of V8 runtimes? Does it specify memory limits via `V8RuntimeConstraints`?
Using React.NET 3.0.1 which uses ClearScript.V8 5.4.8 following hang is observed on recycling application pool
```
.NET Call Stack
.SharedPtr.Release(SharedPtr*)+d7
[[InlinedCallFrame] (.Decrement)] .RefCount.Decrement(RefCount*)
Microsoft.ClearScript.V8.V8ContextProxyImpl.!V8ContextProxyImpl()+4e
Microsoft.ClearScript.V8.V8ContextProxyImpl.Dispose(Boolean)+1f
[[DebuggerU2MCatchHandlerFrame]]
[[ContextTransitionFrame]]
[[GCFrame]]
[[DebuggerU2MCatchHandlerFrame]]
Full Call Stack
ntdll!NtWaitForSingleObject+14
KERNELBASE!WaitForSingleObjectEx+8f
v8_x64!v8::Extension::dependencies+329ac
v8_x64!v8::ExternalResourceVisitor::VisitExternalString+28187
v8_x64!v8::ExternalResourceVisitor::VisitExternalString+1a3
v8_x64!v8::ExternalResourceVisitor::VisitExternalString+533b
ClearScriptV8_64+14216
ClearScriptV8_64+120e4
ClearScriptV8_64+13e3f
ClearScriptV8_64+50a8
<Module>.SharedPtr<V8Context>.Release(SharedPtr<V8Context>*)+d7
[[InlinedCallFrame] (<Module>.Decrement)] <Module>.RefCount.Decrement(RefCount*)
Microsoft.ClearScript.V8.V8ContextProxyImpl.!V8ContextProxyImpl()+4e
Microsoft.ClearScript.V8.V8ContextProxyImpl.Dispose(Boolean)+1f
clr!FastCallFinalizeWorker+6
clr!ETW::GCLog::SendFinalizeObjectEvent+c9
clr!MethodTable::CallFinalizer+b5
clr!CallFinalizer+5e
clr!FinalizerThread::DoOneFinalization+95
clr!FinalizerThread::FinalizeAllObjects+133
clr!FinalizerThread::FinalizeAllObjects_Wrapper+18
clr!Frame::Push+59
clr!PEDecoder::GetNativeCodeManagerTable+170
clr!PEDecoder::GetNativeCodeManagerTable+99
[[DebuggerU2MCatchHandlerFrame]]
clr!Thread::ShouldChangeAbortToUnload+45
clr!Thread::DoADCallBack+109
[[ContextTransitionFrame]]
clr!Frame::Push+a2
clr!FinalizerThread::DoOneFinalization+1f9
[[GCFrame]]
clr!FinalizerThread::FinalizeAllObjects+133
clr!FinalizerThread::FinalizerThreadWorker+bb
clr!Frame::Push+59
clr!PEDecoder::GetNativeCodeManagerTable+170
clr!PEDecoder::GetNativeCodeManagerTable+99
[[DebuggerU2MCatchHandlerFrame]]
clr!FinalizerThread::FinalizerThreadStart+10a
clr!Thread::intermediateThreadProc+86
kernel32!BaseThreadInitThunk+14
ntdll!RtlUserThreadStart+21
```
Comments: An access violation inside native V8 initialization nearly always indicates an out-of-memory condition. When it fails to allocate resources, V8 immediately crashes the process by raising an access violation. At startup, a V8 runtime tries to acquire large amounts of memory and address space to be handed off to its internal resource manager. Any allocation failure leads to an immediate crash. Does your crash always happen _after_ a recycle? Or can it happen randomly at any time? Other questions: Does your application run in a 32-bit process? Is it possible that it creates a large number of V8 runtimes? Does it specify memory limits via `V8RuntimeConstraints`?