[1] I guess in a modern system a process can still trash its own malloc, but not the kernel’s page allocation data.
I will say though, non-Windows machines rarely need a reboot while Windows often should practically be rebooted daily.
[dead]
I should also note this error is the return code for MS-DOS’s memory management functions (such as int 21h ax 48h / 49h), vaguely similar to malloc() returning NULL. It’s not a fatal error, so how it’s handled depends on the programme. It could bail out, perhaps with a more general “out of memory” error, or try and carry on, or perhaps just start overwriting parts of the interrupt vector table as that’s where segment 0007h would start at…
(Though in the latter case on DOS just blindly assuming a memory allocation worked would be rather unwise so you’d hope just about everything checks the carry flag first).
It reminds me of "bitsquatting" where you can get a lot of hits for domains 1 bit off really popular domains (separate from likely typos).
I think it’s largely a factor of what additional drivers, services and security software are installed.
My laptop (very deliberately) only has the integrated Intel GPU, uses vanilla Windows Defender and I avoid installing any additional stuff, e.g, stick to just Dell’s Command | Update as opposed to having any of their other completely unnecessary software installed, also always avoid their SupportAssist.
I also have Windows 11 widgets turned off and have set the registry key which stops web results appearing in the start menu search which changes it to work really well as opposed to constant source of frustration. (Similarly, I found on iOS turning off Safari results from global search also a huge quality of life improvement.)
I've typically seen ~a dozen bitflips per year per machine when I looked at this on servers, except for the cases of a faulty RAM module.
I am more worried about SSD corruption than RAM bitflips from data I've seen on my systems.