If you are asking what Chrome/Flash is doing, then I have no idea, and I can't even begin to guess as the possibilities are probably endless.
If you are wondering why some programs go haywire and take a long time to crash, then the following might help.
The problem arises because, whilst it might be obvious to you that the program is doing something wrong, it is not always obvious to the operating system.
The first thing you need to understand is that normally only one thread is allow to access the User Interface, which includes updating information on screen, responding to keystrokes and mouse events and even redrawing/refreshing the screen (for example when restoring your application after being minimised).
If the main thread is busy, none of this happens. If the main thread is busy for too long, windows will label the program as 'not responding' (by changing the title appear or displaying this status in task manager) but will still allow it to continue since the program may simply be busy. Wait even longer and windows may eventually decide to display a message giving you a chance to kill the program.
It is worth pointing out that if the main thread is busy, that means it will not respond to you attempting to close it (eg by clicking on the close button, or pressing Alt-F4).
To avoid getting into a 'unresponsive' mode, when writing a program, the programmer is supposed to start a new thread for any operations that they think will take a long time. From a programmers point of view, this is more work (which takes time and money), it also makes things more complicated so it is common to only do this when you think you need it.
But problems arise when they don't do it for an operation that they think will only take a few milliseconds but ends up taking much longer.
To give you an example of a misbehaving program, and I'm guessing about what was going on g since I didn't have the source code, but I think this program was expecting to be installed into its own folder (eg c:\program files\xxxx). On startup it was opening every file in all of its subfolders, which normally was just one or two files that it had placed there. It guess it was looking for addons or updates to itself. This operation only took a few milliseconds and obviously wasn't written as a background thread.
Everything worked fine, until along came a user and decided to install it to the root of the company's network share which meant that, instead of opening one or two files, it was opening thousands (or tens of thousands) of files and across the network. The program worked, but was un-responsive for several minutes during this time.
That is the situation as I seen it, so the following is hypothetical
Suppose that instead of thousands of files, there will millions of files. The program might still technically work, but take days to complete this operation. Unless you are extremely patient, you would probably consider this program as having crashed even though it is actually working correctly.
Suppose this program was written to open the whole of these files into memory and suppose some other user happened to save, say a 60GB Ghost Image or backup into the company shared folder. The application would attempt to read all of this file into memory, which would use up all real memory and starting swapping out to disk and getting slower and slower and on most machines it would eventually run out of virtual memory which is a real error and the operating system would step and the program will be killed.
To the end user, he might think it was obvious the program had crashed from the start (when it first become un-responsive), so why does it take, say ten minutes, before finally crashing, but in reality that is not the situation and not how Windows views this. The first ten minutes the program was working fine and only crashed at the very end.
And all because the author of the program did not take into account the fact that some user somewhere would ignore their instructions and ignore the defaults and install the program into the root of a extremely large folder.
Now, I am not saying that this is anything remotely like what is happening with Chrome/Flash, but is more to illustrate the difference between being un-responsive and actually crashing.
