Memory allocation crashes the OS. Who's to blame beside the OS [closed]

Question

This short snippet

#include <new>

int main(){
  while(true){
     try{
        new char[0x10000000];
     }catch(std::bad_alloc bac){
     }
  }
}

apparently crashes the entire operating system when compiled as a 64 bit application and run on a 64 bit Windows system.

This is a valid c++ program. How can this happen? Isn't the msvc compiler at fault here too?

All other compiler/system combinations left the system sluggish at worst.

Don't try this at home. user Christophe tried this on his system and it crashed.

To commenters: I'm not interested in debugging. This is a valid c++ program. My code is not at fault. I'm curious what might induce this behaviour.

Answer 1

One quite plausible scenario for "blue screen when an application is using a lot of memory" is a driver that crashes. There are two common problems here:

1. Driver that can't allocate memory and doesn't detect the NULL returned by allocation function when it couldn't allocate memory", resulting in a NULL [or close to NULL] memory access.

2. Driver doesn't properly "lock" it's memory buffers, leading to pages that the driver "needs" being swapped out when it comes to use the page - this leads to "IRQL Not Less or Equal" blue-screen, which is caused by OS detecting that a page-in request happens when the driver is in a mode where the scheduler is "locked". In other words, the driver asked for "no other task must run until I finish this", and then a page-fault happens that is a request to page in a page from the swap, which indeed requires a different task [the swapper process] to run - can't have the cake and eat it, so OS says "No can do" - can't continue at that point, since the driver is not able to access memory, can't switch to another task, so we can't do anything other than "report error and stop".

3. A third alternative is that the driver detects that it can't allocate memory, but decides that it can not continue and then issues its own blue-screen by calling the "I want to bluescreen now" function in Windows. Drivers that are well written should not do this, but like some driver writers still decide that this is a "good idea".

Sorry, it's been about 11 years since I wrote windows drivers, so the exact error codes one can expect here have gone missing. I think 7B for IRQLNotLessOrEqual, and 0xC00000005 for the access of unmapped memory (NULL access etc).

The fact that several different machines behave the same can easily be explained by many machines having either similar hardware (e.g. same printer, USB [mouse or keyboard?] or CD-ROM drive that is flaky), or by having the same antivirus software - AV software always has a driver component to "hook" into other processes and such.

Given that "really running out of memory" is not so common these days, not so skilled/experienced/conscientious developers may well not test properly with either fake out of memory or real out of memory situations, and thus not detect that their driver fails in this situation.

To give more details, we'd need to know at least the blue-screen "code" (four to five hex-numbers at the top of the screen)

Assuming there is some point to debugging this sort of failure, you can either set up windows to store a a dump (or mini-dump) when it crashes, or use a second PC to connect WinDBG as a remote debugger [or some other remote debugger] to the machine that is crashing - when a machine blue-screens, it will stop in the debugger before restarting, so you can see what the state of the system is, including looking at the callstack of the code that caused the crash - which typically will show what component is actually causing the problem. However, unless you actually have a good contact with the driver developers (at the very least an email address to the relevant support people), it's unlikely much can be achieved to solve this.