Bugzilla

This is caused by a race condition in our interception code indeed. The trampoline address `mOrigFunc` is set *after* we alter the code of the hooked function (see attachment). So if between the two writes, the hooked function gets called on another thread and our patched function calls the trampoline, we will crash. This seems to be most commonly happeining for BaseThreadInitThunk, for which a thread starting between the two writes would result in crash. The crash stack is a bit obscure, but that is because the null pointer dereference happens during CFG checks, which are guarded to force crashing without any possible handling of the exception.

This is caused by a race condition in our interception code indeed. The trampoline address `mOrigFunc` is set *after* we alter the code of the hooked function (see attachment). So if between the two writes, the hooked function gets called on another thread and we reach the part of our patched function that calls the trampoline, we will crash. This seems to be most commonly happeining for BaseThreadInitThunk, for which a thread starting between the two writes would result in crash. The crash stack is a bit obscure, but that is because the null pointer dereference happens during CFG checks, which are guarded to force crashing without any possible handling of the exception.

This is caused by a race condition in our interception code indeed. The trampoline address `mOrigFunc` is set *after* we alter the code of the hooked function (see attachment). So if between the two writes, the hooked function gets called on another thread and we reach the part of our patched function that calls the trampoline, we will crash. This seems to be most commonly happeining for `BaseThreadInitThunk`, for which a thread starting between the two writes would result in crash. The crash stack is a bit obscure, but that is because the null pointer dereference happens during CFG checks, which are guarded to force crashing without any possible handling of the exception.

This is caused by a race condition in our interception code indeed. The trampoline address `mOrigFunc` is set *after* we alter the code of the hooked function (see attachment). So if between the two writes, the hooked function gets called on another thread and we reach the part of our patched function that calls the trampoline, we will crash. This seems to be most commonly happeining for `BaseThreadInitThunk`, for which a thread starting between the two writes would result in crash. The crash stack is a bit obscure, but that is because we crash as a CFG check failure, which is guarded to force crashing without any possible handling of the exception, rather than a regular null pointer dereference.

This is caused by a race condition in our interception code indeed. The trampoline address `mOrigFunc` is set *after* we alter the code of the hooked function (see attachment). So if between the two writes, the hooked function gets called on another thread and we reach the part of our patched function that calls the trampoline, we will crash. This seems to be most commonly happeining for `BaseThreadInitThunk`, for which a thread starting between the two writes would result in crash. The crash stack is a bit obscure, but that is because we crash as a CFG check failure (which are guarded to force crashing without any possible handling of the exception), rather than a regular null pointer dereference.

This is caused by a race condition in our interception code indeed. The trampoline address `mOrigFunc` is set *after* we alter the code of the hooked function (see attachment). So if between the two writes, the hooked function gets called on another thread and we reach the part of our patched function that calls the trampoline, we will crash because `mOrigFunc` still has its `nullptr` initial value. This seems to be most commonly happeining for `BaseThreadInitThunk`, for which a thread starting between the two writes would result in crash. The crash stack is a bit obscure, but that is because we crash as a CFG check failure (which are guarded to force crashing without any possible handling of the exception), rather than a regular null pointer dereference.

This is caused by a race condition in our interception code indeed. The trampoline address `mOrigFunc` is set *after* we alter the code of the hooked function (see attachment). So if between the two writes, the hooked function gets called on another thread and we reach the part of our patched function that calls the trampoline, we will crash because `mOrigFunc` still has its `nullptr` initial value. This seems to be most commonly happening for `BaseThreadInitThunk`, for which a thread starting between the two writes would result in crash. The crash stack is a bit obscure, but that is because we crash as a CFG check failure (which are guarded to force crashing without any possible handling of the exception), rather than a regular null pointer dereference.

This is caused by a race condition in our interception code indeed. The trampoline address `mOrigFunc` is set *after* we alter the code of the hooked function (see attachment). So if between the two writes, the hooked function gets called on another thread and we reach the part of our patched function that calls the trampoline, we will crash because `mOrigFunc` still has its `nullptr` initial value. This seems to be most commonly happening for `BaseThreadInitThunk`, for which a thread starting between the two writes would result in crash. The crash stack is a bit obscure, but that is because we crash as part of a CFG check failure (which are guarded to force crashing without any possible handling of the exception), rather than a regular null pointer dereference.