Bugzilla

The way we call into `AvSetMmThreadCharacteristicsA` makes `xul.dll` depend on `avrt.dll`. We make this dependency use delay-loading, i.e. load the DLL at function call site, due to some sandboxing requirements (see bug 1546154). The crash that we see here is caused by failing to load the DLL at the function call site. It is normal and expected that failure to delay-load a DLL results in a crash.

If there were only child process crashes here, this failure could indicate an issue with sandboxing where the call site would occur too late (after lowering the sandbox). But since there are parent process crashes as well, it seems that it's just not safe in general to rely on the availability of this specific DLL on all user machines.

In order to avoid crashing here, we would need to make sure that we never call into an `avrt.dll` function unless we have first sucessfully loaded the library with a manual call to `LoadLibrary`. In addition to that, we could also consider using `GetProcAddress` rather than delay-loading for interfacing with this library ([like webrtc code does it](https://searchfox.org/mozilla-central/source/third_party/libwebrtc/modules/audio_device/win/audio_device_core_win.cc#407)), which would be a more standard way to depend on a library that can fail to load.

Depending on the importance of these calls, we may also want to add some telemetry about `LoadLibrary` failures for this DLL.

The way we call into `AvSetMmThreadCharacteristicsA` makes `xul.dll` depend on `avrt.dll`. We make this dependency use delay-loading, i.e. load the DLL at function call site, due to some sandboxing requirements (see bug 1546154). The crash that we see here is caused by failing to load the DLL at the function call site. It is normal and expected that failure to delay-load a DLL results in a crash.

If there were only child process crashes here, this failure could indicate an issue with sandboxing where the function call would occur too late (after lowering the sandbox). But since there are parent process crashes as well, it seems that it's just not safe in general to rely on the availability of this specific DLL on all user machines.

In order to avoid crashing here, we would need to make sure that we never call into an `avrt.dll` function unless we have first sucessfully loaded the library with a manual call to `LoadLibrary`. In addition to that, we could also consider using `GetProcAddress` rather than delay-loading for interfacing with this library ([like webrtc code does it](https://searchfox.org/mozilla-central/source/third_party/libwebrtc/modules/audio_device/win/audio_device_core_win.cc#407)), which would be a more standard way to depend on a library that can fail to load.

Depending on the importance of these calls, we may also want to add some telemetry about `LoadLibrary` failures for this DLL.

The way we call into `AvSetMmThreadCharacteristicsA` makes `xul.dll` depend on `avrt.dll`. We make this dependency use delay-loading, i.e. load the DLL at function call site, due to some sandboxing requirements (see bug 1546154). The crash that we see here is caused by failing to load the DLL at the function call site. It is normal and expected that failure to delay-load a DLL results in a crash.

If there were only child process crashes here, this failure could indicate an issue with sandboxing where the function call would occur too late (after lowering the sandbox). But since there are parent process crashes as well, it seems that it's just not safe in general to rely on the availability of this specific DLL on all user machines.

In order to avoid crashing here, we would need to make sure that we never call into an `avrt.dll` function unless we have first sucessfully loaded the library with a common manual call to `LoadLibrary`. In addition to that, we could also consider using `GetProcAddress` rather than delay-loading for interfacing with this library ([like webrtc code does it](https://searchfox.org/mozilla-central/source/third_party/libwebrtc/modules/audio_device/win/audio_device_core_win.cc#407)), which would be a more standard way to depend on a library that can fail to load.

Depending on the importance of these calls, we may also want to add some telemetry about `LoadLibrary` failures for this DLL.

The way we call into `AvSetMmThreadCharacteristicsA` (and other `avrt.dll` functions) makes `xul.dll` depend on `avrt.dll`. We make this dependency use delay-loading, i.e. load the DLL at function call site, due to some sandboxing requirements (see bug 1546154). The crash that we see here is caused by failing to load the DLL at the function call site. It is normal and expected that failure to delay-load a DLL results in a crash.

If there were only child process crashes here, this failure could indicate an issue with sandboxing where the function call would occur too late (after lowering the sandbox). But since there are parent process crashes as well, it seems that it's just not safe in general to rely on the availability of this specific DLL on all user machines.

In order to avoid crashing here, we would need to make sure that we never call into an `avrt.dll` function unless we have first sucessfully loaded the library with a common manual call to `LoadLibrary`. In addition to that, we could also consider using `GetProcAddress` rather than delay-loading for interfacing with this library ([like webrtc code does it](https://searchfox.org/mozilla-central/source/third_party/libwebrtc/modules/audio_device/win/audio_device_core_win.cc#407)), which would be a more standard way to depend on a library that can fail to load.

Depending on the importance of these calls, we may also want to add some telemetry about `LoadLibrary` failures for this DLL.