Bugzilla

Following mozregression and initial suspicious by :mccr8, I'm marking bug 1970638 as a regressor.

Based on debugging, the DLLs load on the main thread after Trend Micro queues a [user-mode APC](https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls).

Since the landing of the patch in bug 1970638, once the main thread of a sandboxed content process calls `RevertToSelf` to start the sandbox, it remains possible to load well-known DLLs. Before that patch, loading a well-known DLL would fail once the sandbox is started. As noted by :bobowen, the Trend Micro DLLs depend on `psapi.dll`, which is a well-known DLL.

I suspect that there could be a race condition between the point where the user-mode APC gets called and the call to `RevertToSelf`. More precisely, the crashes could be occuring when the DLLs successfully load *after* the sandbox is started. Before bug 1970638, the DLLs would fail to load if the sandbox is started because of their dependency on `psapi.dll`. After bug 1970638, they will still successfully load, but they might not expect to be running in a sandboxed environment where some initialization calls would fail.

We have not confirmed this theory, but it sounds like a good starting point if Trend Micro wants to address this issue in the DLLs directly.

Following mozregression and initial suspicious by :mccr8, I'm marking bug 1970638 as a regressor.

Based on debugging, the DLLs load on the main thread after Trend Micro queues a [user-mode APC](https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls).

Since the landing of the patch in bug 1970638, after the main thread of a sandboxed content process calls `RevertToSelf` to start the sandbox, it remains possible to load well-known DLLs. Before that patch, loading a well-known DLL would fail once the sandbox is started. As noted by :bobowen, the Trend Micro DLLs depend on `psapi.dll`, which is a well-known DLL.

I suspect that there could be a race condition between the point where the user-mode APC gets called and the call to `RevertToSelf`. More precisely, the crashes could be occuring when the DLLs successfully load *after* the sandbox is started. Before bug 1970638, the DLLs would fail to load if the sandbox is started because of their dependency on `psapi.dll`. After bug 1970638, they will still successfully load, but they might not expect to be running in a sandboxed environment where some initialization calls would fail.

We have not confirmed this theory, but it sounds like a good starting point if Trend Micro wants to address this issue in the DLLs directly.

Following mozregression and initial suspicious by :mccr8, I'm marking bug 1970638 as a regressor.

Based on debugging, the DLLs load on the main thread after Trend Micro queues a [user-mode APC](https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls).

Since the landing of the patch in bug 1970638, after the main thread of a sandboxed content process calls `RevertToSelf` to start the sandbox, it remains possible to load well-known DLLs. Before that patch, loading a well-known DLL would fail once the sandbox is started. As noted by :bobowen, the Trend Micro DLLs depend on `psapi.dll`, which is a well-known DLL.

I suspect that there could be a race condition between the point where the user-mode APC gets called and the call to `RevertToSelf`. More precisely, the crashes could be occuring when the DLLs successfully load *after* the sandbox is started. Before bug 1970638, the DLLs would fail to load if the sandbox is started because of their dependency on `psapi.dll`. After bug 1970638, they will successfully load but they might not expect to be running in a sandboxed environment where some initialization calls would fail, ultimately causing crashes.

We have not confirmed this theory, but it sounds like a good starting point if Trend Micro wants to address this issue in the DLLs directly.

Following mozregression and initial suspicious by :mccr8, I'm marking bug 1970638 as a regressor.

Based on debugging, the DLLs load on the main thread after Trend Micro queues a [user-mode APC](https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls).

Since the landing of the patch in bug 1970638, after the main thread of a sandboxed content process calls `RevertToSelf` to start the sandbox, it remains possible to load well-known DLLs. Before that patch, loading a well-known DLL would fail once the sandbox is started. As noted by :bobowen, the Trend Micro DLLs depend on `psapi.dll`, which is a well-known DLL.

We suspect that there could be a race condition between the point where the user-mode APC gets called and the call to `RevertToSelf`. More precisely, the crashes could be occuring when the DLLs successfully load *after* the sandbox is started. Before bug 1970638, the DLLs would fail to load if the sandbox is started because of their dependency on `psapi.dll`. After bug 1970638, they will successfully load but they might not expect to be running in a sandboxed environment where some initialization calls would fail, ultimately causing crashes.

We have not confirmed this theory, but it sounds like a good starting point if Trend Micro wants to address this issue in the DLLs directly.

Following mozregression and initial suspicious by :mccr8, I'm marking bug 1970638 as a regressor.

Based on debugging, the DLLs load on the main thread after Trend Micro queues a [user-mode APC](https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls).

Since the landing of the patch in bug 1970638, after the main thread of a sandboxed content process calls `RevertToSelf` to start the sandbox, it remains possible to load well-known DLLs. Before that patch, loading a well-known DLL would fail once the sandbox is started. As noted by :bobowen, the Trend Micro DLLs depend on `psapi.dll`, which is a well-known DLL.

We suspect that there could be a race condition between the point where the user-mode APC gets called and the call to `RevertToSelf`. More precisely, the crashes could be occuring when the DLLs successfully load *after* the sandbox is started. Before bug 1970638, the DLLs would fail to load if the sandbox is started because of their dependency on `psapi.dll`. After bug 1970638, they will successfully load but they might not expect to be running in a sandboxed environment where some initialization calls would fail, ultimately causing crashes.

We have not confirmed this theory, but it sounds like a good starting point for investigation if Trend Micro wants to address this issue in the DLLs directly.

Following mozregression and initial suspicious by :mccr8, I'm marking bug 1970638 as a regressor.

Based on debugging, the DLLs load on the main thread after Trend Micro queues a [user-mode APC](https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls).

Since the landing of the patch in bug 1970638, after the main thread of a sandboxed content process calls `RevertToSelf` to start the sandbox, it remains possible to load well-known DLLs. Before that patch, loading a well-known DLL would fail once the sandbox is started. As noted by :bobowen, the Trend Micro DLLs depend on `psapi.dll`, which is a well-known DLL.

We suspect that there could be a race condition between the non-deterministic point where the user-mode APC gets called and the call to `RevertToSelf`. More precisely, the crashes could be occuring when the DLLs successfully load *after* the sandbox is started. Before bug 1970638, the DLLs would fail to load if the sandbox is started, because of their dependency on `psapi.dll`. After bug 1970638, they will successfully load and they might not expect to be running in a sandboxed environment where some initialization calls would fail, ultimately causing crashes.

We have not confirmed this theory, but it sounds like a good starting point for investigation if Trend Micro wants to address this issue in the DLLs directly.

Following mozregression and initial suspicious by :mccr8, I'm marking bug 1970638 as a regressor.

Since the landing of the patch in bug 1970638, after the main thread of a sandboxed content process calls `RevertToSelf` to start the sandbox, it remains possible to load well-known DLLs. Before that patch, loading a well-known DLL would fail once the sandbox is started. As noted by :bobowen, the Trend Micro DLLs depend on `psapi.dll`, which is a well-known DLL.

Based on debugging, the Trend Micro DLLs load on the main thread after Trend Micro queues a [user-mode APC](https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls).

We suspect that there could be a race condition between the non-deterministic point where the user-mode APC gets called and the call to `RevertToSelf`. More precisely, the crashes could be occuring when the DLLs successfully load *after* the sandbox is started. Before bug 1970638, the DLLs would fail to load if the sandbox is started, because of their dependency on `psapi.dll`. After bug 1970638, they will successfully load and they might not expect to be running in a sandboxed environment where some initialization calls would fail, ultimately causing crashes.

We have not confirmed this theory, but it sounds like a good starting point for investigation if Trend Micro wants to address this issue in the DLLs directly.

Following mozregression and initial suspicious by :mccr8, I'm marking bug 1970638 as a regressor.

Since the landing of the patch in bug 1970638, after the main thread of a sandboxed content process calls `RevertToSelf` to start the sandbox, it remains possible to load well-known DLLs. Before that patch, loading any well-known DLL would fail once the sandbox is started. As noted by :bobowen, the Trend Micro DLLs depend on `psapi.dll`, which is a well-known DLL.

Based on debugging, the Trend Micro DLLs load on the main thread after Trend Micro queues a [user-mode APC](https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls).

We suspect that there could be a race condition between the non-deterministic point where the user-mode APC gets called and the call to `RevertToSelf`. More precisely, the crashes could be occuring when the DLLs successfully load *after* the sandbox is started. Before bug 1970638, the DLLs would fail to load if the sandbox is started, because of their dependency on `psapi.dll`. After bug 1970638, they will successfully load and they might not expect to be running in a sandboxed environment where some initialization calls would fail, ultimately causing crashes.

We have not confirmed this theory, but it sounds like a good starting point for investigation if Trend Micro wants to address this issue in the DLLs directly.

Following mozregression and initial suspicious by :mccr8, I'm marking bug 1970638 as a regressor.

Since the landing of the patch in bug 1970638, after the main thread of a sandboxed content process calls `RevertToSelf` to start the sandbox, it remains possible to load well-known DLLs. Before that patch, loading any well-known DLL would fail once the sandbox is started.

As noted by :bobowen, the Trend Micro DLLs depend on `psapi.dll`, which is a well-known DLL. And based on debugging, the Trend Micro DLLs load on the main thread after Trend Micro queues a [user-mode APC](https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls).

We suspect that there could be a race condition between the non-deterministic point where the user-mode APC gets called and the call to `RevertToSelf`. More precisely, the crashes could be occuring when the DLLs successfully load *after* the sandbox is started. Before bug 1970638, the DLLs would fail to load if the sandbox is started, because of their dependency on `psapi.dll`. After bug 1970638, they will successfully load and they might not expect to be running in a sandboxed environment where some initialization calls would fail, ultimately causing crashes.

We have not confirmed this theory, but it sounds like a good starting point for investigation if Trend Micro wants to address this issue in the DLLs directly.

Following mozregression and initial suspicious by :mccr8, I'm marking bug 1970638 as a regressor.

Since the landing of the patch in bug 1970638, after the main thread of a sandboxed content process calls `RevertToSelf` to start the sandbox, it remains possible to load well-known DLLs. Before that patch, loading any well-known DLL would fail once the sandbox is started.

As noted by :bobowen, the Trend Micro DLLs depend on `psapi.dll`, which is a well-known DLL that doesn't load during normal content process initialization. And based on debugging, the Trend Micro DLLs load on the main thread after Trend Micro queues a [user-mode APC](https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls).

We suspect that there could be a race condition between the non-deterministic point where the user-mode APC gets called and the call to `RevertToSelf`. More precisely, the crashes could be occuring when the DLLs successfully load *after* the sandbox is started. Before bug 1970638, the DLLs would fail to load if the sandbox is started, because of their dependency on `psapi.dll`. After bug 1970638, they will successfully load and they might not expect to be running in a sandboxed environment where some initialization calls would fail, ultimately causing crashes.

We have not confirmed this theory, but it sounds like a good starting point for investigation if Trend Micro wants to address this issue in the DLLs directly.

Following mozregression and initial suspicious by :mccr8, I'm marking bug 1970638 as a regressor.

Since the landing of the patch in bug 1970638, after the main thread of a sandboxed content process calls `RevertToSelf` to start the sandbox, it remains possible to load well-known DLLs. Before that patch, loading any well-known DLL would fail once the sandbox is started.

As noted by :bobowen, the Trend Micro DLLs depend on `psapi.dll`, which is a well-known DLL that Firefox itself does not load during content process initialization. And based on debugging, the Trend Micro DLLs load on the main thread after Trend Micro queues a [user-mode APC](https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls).

We suspect that there could be a race condition between the non-deterministic point where the user-mode APC gets called and the call to `RevertToSelf`. More precisely, the crashes could be occuring when the DLLs successfully load *after* the sandbox is started. Before bug 1970638, the DLLs would fail to load if the sandbox is started, because of their dependency on `psapi.dll`. After bug 1970638, they will successfully load and they might not expect to be running in a sandboxed environment where some initialization calls would fail, ultimately causing crashes.

We have not confirmed this theory, but it sounds like a good starting point for investigation if Trend Micro wants to address this issue in the DLLs directly.

Following mozregression and initial suspicious by :mccr8, I'm marking bug 1970638 as a regressor.

Since the landing of the patch in bug 1970638, after the main thread of a sandboxed content process calls `RevertToSelf` to start the sandbox, it remains possible to load well-known DLLs. Before that patch, loading any well-known DLL would fail once the sandbox is started.

As noted by :bobowen, the Trend Micro DLLs depend on `psapi.dll`, which is a well-known DLL that Firefox itself does not load during content process initialization. And based on debugging, the Trend Micro DLLs load on the main thread after Trend Micro queues a [user-mode APC](https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls).

We suspect that there could be a race condition between the non-deterministic point where the user-mode APC gets called and the call to `RevertToSelf` that starts the sandbox. More precisely, the crashes could be occuring when the DLLs successfully load *after* the sandbox is started. Before bug 1970638, the DLLs would fail to load if the sandbox is started, because of their dependency on `psapi.dll`. After bug 1970638, they will successfully load and they might not expect to be running in a sandboxed environment where some initialization calls would fail, ultimately causing crashes.

We have not confirmed this theory, but it sounds like a good starting point for investigation if Trend Micro wants to address this issue in the DLLs directly.

Following mozregression and initial suspicious by :mccr8, I'm marking bug 1970638 as a regressor.

Since the landing of the patch in bug 1970638, after the main thread of a sandboxed content process calls `RevertToSelf` to start the sandbox, it remains possible to load well-known DLLs. Before that patch, loading any well-known DLL would fail once the sandbox is started.

As noted by :bobowen, the Trend Micro DLLs depend on `psapi.dll`, which is a well-known DLL that Firefox itself does not load during content process initialization. And based on debugging, the Trend Micro DLLs load on the main thread after Trend Micro queues a [user-mode APC](https://learn.microsoft.com/en-us/windows/win32/sync/asynchronous-procedure-calls).

We suspect that there could be a race condition between the non-deterministic point where the user-mode APC gets called and the call to `RevertToSelf` that starts the sandbox. More precisely, the crashes could be occuring when the DLLs successfully load *after* the sandbox is started. Before bug 1970638, the DLLs would fail to load if the sandbox is started, because of their dependency on `psapi.dll`. After bug 1970638, they will successfully load and they might not expect to be running their initialization code in a sandboxed environment where some initialization calls would fail, ultimately causing crashes.

We have not confirmed this theory, but it sounds like a good starting point for investigation if Trend Micro wants to address this issue in the DLLs directly.