Can someone explain to me... | The Coffeehouse

...what happens behind the scenes when using your average Windows OS. A piece of software crashes/sticks/pauses. You opt for the Task Manager to 'End Task', then said software remerges from hibernation?

Out of interest.

Thanks

alwaysmc2

mikexkearney wrote:

...what happens behind the scenes when using your average Windows OS. A piece of software crashes/sticks/pauses. You opt for the Task Manager to 'End Task', then said software remerges from hibernation?

Out of interest.

Thanks

I have noticed that! Sometimes it seems like when Windows will threaten to kill it, so the program decides to quit being lazy. Tongue Out

That happend a while ago... I don't remember if it was on XP or Vista.

W3bbo

alwaysmc2 wrote:

mikexkearney wrote:...what happens behind the scenes when using your average Windows OS. A piece of software crashes/sticks/pauses. You opt for the Task Manager to 'End Task', then said software remerges from hibernation?

Out of interest.

Thanks

I have noticed that! Sometimes it seems like when Windows will threaten to kill it, so the program decides to quit being lazy. That happend a while ago... I don't remember if it was on XP or Vista.

It's a fairly simple problem, the main thread got stuck doing something, but the window message handling thread sat up and took notice of the terminate message and canned the stuck thread.

BruceMorgan

mikexkearney wrote:

...what happens behind the scenes when using your average Windows OS. A piece of software crashes/sticks/pauses. You opt for the Task Manager to 'End Task', then said software remerges from hibernation?

Out of interest.

Thanks

Coincidence.

And I don't understand "crashing" alongside "sticks/pauses". A crashed app doesn't need to be terminated...

Isshou

It seems that Windows is actually a lot nicer at killing programs then you can be, instead of the "kill -9 pid" surefire kill you can do, it will just do a "kill pid", which while it does send the termination command to the (program) it will not check to see if the (program) does terminate itself. So whatever the (program) does with that termination command may be up to the (program). It could very well treat it as an abort whatever it is doing or it might just have that side effect, afterwards it couldn't process the comman to termination but it is now mystically responsive again. This is mostly just observational, I don't know what Windows really does behind the scenes, but it's probably not that different.

BruceMorgan

W3bbo wrote:

alwaysmc2 wrote:

mikexkearney wrote: ...what happens behind the scenes when using your average Windows OS. A piece of software crashes/sticks/pauses. You opt for the Task Manager to 'End Task', then said software remerges from hibernation?

Out of interest.

Thanks

I have noticed that! Sometimes it seems like when Windows will threaten to kill it, so the program decides to quit being lazy. That happend a while ago... I don't remember if it was on XP or Vista.

It's a fairly simple problem, the main thread got stuck doing something, but the window message handling thread sat up and took notice of the terminate message and canned the stuck thread.

Wha??? What you describe doesn't exist...

The "window message handling thread" is the main thread in the vast majority of GUI Windows apps. Unless the developer coded otherwise, everything is on that thread. And multiple UI threads are a hassle and a half, so most people who do multithreading have non-GUI background threads.

Sven Groot

Windows will only consider an app not responding if its GUI thread is not pumping messages. If it revives after clicking end task, that is indeed coincidence.

And Bruce, interesting that you say multiple UI threads are a hassle, considering that IE7 is one of the few apps that uses that. Smiley

W3bbo

Isshou wrote:

It seems that Windows is actually a lot nicer at killing programs then you can be, instead of the "kill -9 pid" surefire kill you can do, it will just do a "kill pid", which while it does send the termination command to the (program) it will not check to see if the (program) does terminate itself. So whatever the (program) does with that termination command may be up to the (program). It could very well treat it as an abort whatever it is doing or it might just have that side effect, afterwards it couldn't process the comman to termination but it is now mystically responsive again. This is mostly just observational, I don't know what Windows really does behind the scenes, but it's probably not that different.

Windows needs a kill -9 command somewhere because taskkill /F cannot kill everything, like crashed VM instances and some other voodoo processes (not counting Robin Hood-type viruses here however).

BruceMorgan wrote:
Wha??? What you describe doesn't exist...

The "window message handling thread" is the main thread in the vast majority of GUI Windows apps. Unless the developer coded otherwise, everything is on that thread. And multiple UI threads are a hassle and a half, so most people who do multithreading have non-GUI background threads.

My bad. I assumed it was commonplace to put winproc on its own thread.

Bass

Isshou wrote:

It seems that Windows is actually a lot nicer at killing programs then you can be, instead of the "kill -9 pid" surefire kill you can do, it will just do a "kill pid", which while it does send the termination command to the (program) it will not check to see if the (program) does terminate itself. So whatever the (program) does with that termination command may be up to the (program). It could very well treat it as an abort whatever it is doing or it might just have that side effect, afterwards it couldn't process the comman to termination but it is now mystically responsive again. This is mostly just observational, I don't know what Windows really does behind the scenes, but it's probably not that different.

I don't think Windows has UNIX signals. It can send a message WM_CLOSE to a GUI thread to request it to close or it just force it closed. I think Task Manager just forces it closed.

stevo_

I would imagine its purely because in some cases, Windows cannot even get enough processing time to send the analyze 'is the process hung'. This would go with those processes that hang because their stuck doing infinite processing that is using the processing time up.

The fact the message appears and the program starts to respond would then only be that the program has started to response and now windows finally gets enough time to process and display its 'this programs being naughty' notice.

Thats just a massive guesstimation, of course I know little about the internals of the scheduling, or what part of the OS is in charge of determining if a process may have hung..

Isshou

Bass wrote:

I don't think Windows has UNIX signals. It can send a message WM_CLOSE to a GUI thread to request it to close or it just force it closed. I think Task Manager just forces it closed.

Obviously you didn't catch my usage of quotes, I know windows doesn't have the unix signals. However the unix signals express the matter better, as Task Manager will send a message for termination and not check to make sure the program has terminated (this is like the kill pid unix signal) instead of sending the termination command then checking to make sure the program terminated and if it didn't terminate the program externally (this is like the kill -9 pid). Windows technically doesn't have anything equivilent to the "kill -9 pid" because as w3bbo commented

W3bbo wrote:
because taskkill /F cannot kill everything, like crashed VM instances and some other voodoo processes (not counting Robin Hood-type viruses here however).

Isshou

stevo_ wrote:

I would imagine its purely because in some cases, Windows cannot even get enough processing time to send the analyze 'is the process hung'. This would go with those processes that hang because their stuck doing infinite processing that is using the processing time up.

The fact the message appears and the program starts to respond would then only be that the program has started to response and now windows finally gets enough time to process and display its 'this programs being naughty' notice.

Thats just a massive guesstimation, of course I know little about the internals of the scheduling, or what part of the OS is in charge of determining if a process may have hung..

Fortunately this won't happen in the Windows environment. The developers of the scheduler were smart enough to know how to prevent starvation of other processes. The scheduler will eventually raise the priority of the threads not getting any execution time, most processes associated with task manager would likely be pre-emptive and take away the current time slice to preform its action, since the Windows scheduler allows pre-emptive scheduling for things like interrupts and other things as such.

Windows has a sort of hybrid of round-robin/priority scheduling with pre-emption, with process priority elevation to prevent starvation.