Bugzilla

I closed that bug again: Toshihito confirmed the DLL blocklist is entirely static (it needs to work before we load any Windows networking DLLs!), and doesn't update over the net.

Looking at the crash log, the stack pasted here is corrupt and not the actual one the warning came from:
```
[task 2022-01-13T08:13:06.839Z] 08:13:06     INFO -  Thread 7 Socket Thread (crashed)
[task 2022-01-13T08:13:06.839Z] 08:13:06     INFO -   0  xul.dll!mozilla::net::Http3Stream::OnReadSegment(char const*, unsigned int, unsigned int*) [Http3Stream.cpp:08d254139525017ceb5f98be59d3a5864adbf331 : 273 + 0x0]
[task 2022-01-13T08:13:06.840Z] 08:13:06     INFO -   1  xul.dll!static mozilla::net::nsHttpTransaction::ReadRequestSegment(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*) [nsHttpTransaction.cpp:08d254139525017ceb5f98be59d3a5864adbf331 : 735 + 0x20]
[task 2022-01-13T08:13:06.841Z] 08:13:06     INFO -   2  xul.dll!nsBufferedInputStream::ReadSegments(nsresult (*)(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*), void*, unsigned int, unsigned int*) [nsBufferedStreams.cpp:08d254139525017ceb5f98be59d3a5864adbf331 : 433 + 0x21]
```
But it's not obvious who was doing what that caused the action on the Socket Thread. While this happened the DLL Blocklist and third party stuff was indeed running, but that seems to be because they were still busy hashing the DLLs injected into Firefox, and they're not necessarily the origin of the network query.

I closed that bug again: Toshihito confirmed the DLL blocklist is entirely static (it needs to work before we load any Windows networking DLLs!), and doesn't update over the net.

Looking at the crash log, the stack pasted is corrupt and not the actual one the warning came from:
```
[task 2022-01-13T08:13:06.839Z] 08:13:06     INFO -  Thread 7 Socket Thread (crashed)
[task 2022-01-13T08:13:06.839Z] 08:13:06     INFO -   0  xul.dll!mozilla::net::Http3Stream::OnReadSegment(char const*, unsigned int, unsigned int*) [Http3Stream.cpp:08d254139525017ceb5f98be59d3a5864adbf331 : 273 + 0x0]
[task 2022-01-13T08:13:06.840Z] 08:13:06     INFO -   1  xul.dll!static mozilla::net::nsHttpTransaction::ReadRequestSegment(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*) [nsHttpTransaction.cpp:08d254139525017ceb5f98be59d3a5864adbf331 : 735 + 0x20]
[task 2022-01-13T08:13:06.841Z] 08:13:06     INFO -   2  xul.dll!nsBufferedInputStream::ReadSegments(nsresult (*)(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*), void*, unsigned int, unsigned int*) [nsBufferedStreams.cpp:08d254139525017ceb5f98be59d3a5864adbf331 : 433 + 0x21]
```
But it's not obvious who was doing what that caused the action on the Socket Thread, as it's just processing a message from its event loop. While this happened the DLL Blocklist and third party stuff was indeed running, but that seems to be because they were still busy hashing the DLLs injected into Firefox, and they're not necessarily the origin of the network query.

I closed that bug again: Toshihito confirmed the DLL blocklist is entirely static (it needs to work before we load any Windows networking DLLs!), and doesn't update over the net.

Looking at the crash log, the stack pasted is corrupt and not the actual one the warning came from:
```
[task 2022-01-13T08:13:06.839Z] 08:13:06     INFO -  Thread 7 Socket Thread (crashed)
[task 2022-01-13T08:13:06.839Z] 08:13:06     INFO -   0  xul.dll!mozilla::net::Http3Stream::OnReadSegment(char const*, unsigned int, unsigned int*) [Http3Stream.cpp:08d254139525017ceb5f98be59d3a5864adbf331 : 273 + 0x0]
[task 2022-01-13T08:13:06.840Z] 08:13:06     INFO -   1  xul.dll!static mozilla::net::nsHttpTransaction::ReadRequestSegment(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*) [nsHttpTransaction.cpp:08d254139525017ceb5f98be59d3a5864adbf331 : 735 + 0x20]
[task 2022-01-13T08:13:06.841Z] 08:13:06     INFO -   2  xul.dll!nsBufferedInputStream::ReadSegments(nsresult (*)(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*), void*, unsigned int, unsigned int*) [nsBufferedStreams.cpp:08d254139525017ceb5f98be59d3a5864adbf331 : 433 + 0x21]
(there's more, but nothing revealing the problem)
(and here we see some DLL Blocklist stack simply because that patched the threadstart, unrelated to the problem)
```
But it's not obvious who was doing what that caused the action on the Socket Thread, as it's just processing a message from its event loop. While this happened the DLL Blocklist and third party stuff was indeed running, but that seems to be because they were still busy hashing the DLLs injected into Firefox, and they're not necessarily the origin of the network query.