Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

This is one of the things I've always been interested in, particularly with Windows applications at hand.

Recently, my Chrome browser has often started to crash due to Shockwave Flash plugin. Don't know why specifically, but it ususally crashes the entire browser instead of just one tab ... but that's okey!

What I'm interested in, is that during that crashing time, the whole browser (all tabs) becomes unresponsive until it figures out it's crashing (gives out a dialog window). What does it do during that time (which can take up to 5 - 10 minutes(!) and my laptop is maybe a year old, if even so ...)?

share|improve this question

closed as not constructive by Nifle, Moab, ChrisF, techie007, Tom Wijsman Nov 16 '11 at 13:08

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Hard to say if the OS is having problems with the app crash or the application itself is trying to deal with it. –  Moab Nov 12 '11 at 17:21
    
@Moab - Well, assume one. What does it do in either case? –  ldigas Nov 12 '11 at 18:16
    
Great question and I really hope that someone gives us an answer. For now, the best way to actually see what is happening would be to run the program in a debugger and step through it. I haven't seen the Chrome source, but my guess is that somewhere in the browser there's a watchdog timer which is used to detect lock-ups. Another option is that there could be for example memory leak somewhere and the browser continues working until it tries to write outside of memory assigned to it. –  AndrejaKo Nov 12 '11 at 19:28
1  
Too many variables, depending on how the software was coded to deal with a crash, what type of crash, did the app itself crash or did the app cause the OS to step in and crash the program to protect itself etc, etc, etc. –  Moab Nov 12 '11 at 21:11
1  
In general - it keeps probing the app for a response. If there's no response, then it gives the app a chance to close gracefully. If that doesn't happen then you get the dialog –  Sathya Nov 14 '11 at 8:11
show 3 more comments

3 Answers

up vote 6 down vote accepted

Coming from a programmer, when a program crashes under Windows, and there is no explicit exception (i.e. unhandled thread, accessing deleted memory should all show a specific error), then it's more than likely there was an infinite loop caused by content on one of those particular websites, or the plugin itself (or what the plugin runs).

There's little you can do in these cases, except:

1) Make sure the content is the problem, not your PC.
2) Download the Flash file and see if you can run it locally.
3) See if anyone else has the same problem.

Again though, the browser becomes unresponsive because something is stuck in an infinite polling loop, eating up 100% of your CPU (for example, a while(!condition) loop waiting for condition). During this time, Windows usually notices the process is in this state, and will warn you that this has occurred (and thus why the application stops responding - it's too busy checking something to even respond to the DWM or the OS itself!).

share|improve this answer
add comment

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.

share|improve this answer
add comment

Most likely your browser isn't "crashing", it's "hanging" -- some sort of deadlock situation, a "tight loop" (recognizable by a steady CPU light), or some other situation where all inputs are disabled. The OS then notices that the application is unresponsive (after giving it a "reasonable" time to respond) and kills it.

You can recover from this situation a bit faster by doing Ctrl-Alt-Del, selecting "Start Task Manager", and then selecting and killing your browser process. (Sometimes there may be multiple browser processes. I've even seen a few cases where killing one (the right one) of multiple browser processes would "free up" the browser and allow it to recover.)

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.