> Many projects including Chromium, boringssl, Firefox, and Rust call SystemFunction036 from advapi32.dll because it worked on versions older than Windows 8.

That's not true. They use ProcessPrng since versions earlier than 10 are no longer supported (well, rust also has a windows 7 target but that couldn't use ProcessPrng anyway since it wasn't available). The issue they linked is from a decade ago. E.g. here's Chromium: https://github.com/chromium/chromium/blob/dc7016d1ef67e3e128...

> If [ProcessPrng] fails it returns NO_MEMORY in a BOOL (documented behavior is to never fail, and always return TRUE).

From Windows 10 onward ProcessPrng will never fail. There's a whitepaper that gives the justification for this (https://aka.ms/win10rng):

> We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request...

> For each user-mode process, we have a (buffered) base PRNG maintained by BCryptPrimitives.dll. When this DLL loads it requests a random seed from kernel mode (where it is produced by the per-CPU states) and seeds the process base PRNG. If this were to fail, BCryptPrimitive.dll fails to load, which in most cases causes the process to terminate. This behavior ensures that we never have to return an error code from the RNG system.