Why is the mouse able to hover above almost all computer freezes?

Factual Questions
1

I’m sure I’m not the only one who notices this, but on the occasions that my computer freezes, the mouse still works. It could be a temporary freeze, like if I opened too many windows or something CPU intensive is loading, or it could be a total computer freeze that requires you to actually push the reset button or turn the thing off. In almost all instances, I can move the mouse around just fine. Sure I can’t click on anything, but the computer registers mouse movement without any problems.

Like the joke about the airplane black box (“if a black box is indestructible, why don’t they make the whole plane out of that?”), it makes me wonder why they can’t make everything, or at least the popular word programs or web browsers out of the same near-unfreezable programming that controls the mouse? And its not like its only one computer. In all of the computers I’ve had at home and the ones I’ve used at work, the same thing applies. The mouse almost never freezes and can work when the rest of the computer is just a static screen. I would love to be able to instantly open like 20 tabs and 5 programs and be able to switch between them without pause instead of waiting impatiently for each one to slowly load and hoping I didn’t open too many windows and my computer crashes or something

2

I know the answer (or rather what I heard) about the black box on an airplane being used to make the airplane is because the black box material is too heavy and would never allow the airplane to get off the ground.

Maybe the mouse/cursor has the same thing. And in my experience using a desktop the mouse still works but whenever I’ve frozen with my laptop the trackpad/touchpad doesn’t work.

3

There are a lot of variations between operating systems, but most pointer updates are interrupt-driven. In other words, there is a periodic “ticker” (usually timed to the vertical refresh of the screen) that calls the mouse update and display routines. Since this software is executed by a clock, it is not dependent on how busy the rest of the processor is. Assuming that the processor isn’t so swamped that it can’t even execute the interrupt routine, which would be bad.

4

This isn’t really an answer, but it’s been my experience that in terms of Windows crashing if you lose the mouse abandon all hope (short of a reboot anyway)…

5

(This is an hobbyist’s understanding. I’m not a computer scientist, so correct me if I’m wrong.)

Modern computer operating systems are usually built in layers, kinda like how the human brain is separated into parts ranging from the primitive and unconscious (breathing, blinking, etc.) to the higher-order functions (talking, drawing) that require more thinking.

In a computer environment like Windows, things like basic mouse movement or drawing the screen are considered so primitive/important that they’re given higher priority than most other processor functions, and the system continually checks for them even at the expense of higher-level processing – kinda like how your nervous system will alert you to a sudden jab in the face even if you’re busy taking a test.

In humans, it’s evolution. In computers, it’s both a matter of design priorities and computing difficulty.

In terms of design, it’s possible to build a system where other functions take priority over mouse or keyboard input, but such a system would be harder for humans to interact with in the event of a software bug or system failure. If you had a system that was really good at opening tabs but really bad at handling the mouse, for example, maybe a software bug will cause it to start opening tabs at the rate of 20 a second, at which point it’ll be too overloaded to deal with your mouse and keyboard at all and you’ll have no way of stopping it short of turning off the whole system. On the other hand, if your inputs are a higher priority than other things, at least you stand a chance in hell (through CTRL-ALT-DELETE) of telling the system “STOP THIS WAYWARD PROGRAM THE FIRST CHANCE YOU GET!” and saving the rest of the system. In the real world, most systems try to strike a balance; in server environments, for example, the mouse is often altogether ignored and even the keyboard is mostly ignored or at least significantly de-prioritized unless you push certain special key overrides to tell it to listen up immediately.

In terms of computing difficulty, a browser is a very complex program compared to a mouse. A mouse sends simple signals like “up” “left” “click”, etc. It’s easier to write a program (or design a processor) to handle that. A browser, on the other hand, is a very high-level program, meaning it depends on every other layer below it to properly function (reading from hard drive and memory, networking, graphics, input, antivirus/security restrictions, etc.).

Personal computers are general-purpose computing devices that can do pretty much anything. Contrast this with other personal electronics, like a microwave oven or a television, which are purpose-built and optimized for a much more limited range of functions. It’s hard enough to make a device that does one thing well; it’s much harder to make a device like a computer that’s expected to do everything it’s capable of flawlessly.

To use a car analogy: Making a computer that always responds to the mouse is like making a car that always responds to the steering wheel – mostly doable. But making a computer that always responds to 20 tabs and 5 programs is like making a car that always responds to the steering wheel while it simultaneously plays the radio, investigates upcoming traffic, navigates across the country, drives itself, and bakes bread in the trunk while on fire and underwater… somewhat more difficult.

6

I’m a computer scientist and programmer, and Reply above sounds on the money to me.

Bizarrely enough, though, when I was doing vidcapping on my desktop, if I left it running for a long time, that would freeze up the mouse while the video playback and saving capture images continued fine. I never really figured out why.

But I was able to unfreeze the mouse by hitting control-alt-delete, and then cancelling out of the ‘What do you want to do now?’ control-alt-delete dialog box. Then I could go use the mouse to stop the video playback and the little helper program that I wrote to automatically hit the ‘C’ key every second. (This was with cyberlink PowerDVD, which takes a screen capture when you hit that key.)

7

beowulff touched on this, but software that controls peripherals is typically interrupt driven. I.e. the processor can be going along it’s merry way and you move your mouse or press a key and the mouse/keyboard triggers an interrupt on the processor, which is essentially it saying, “excuse me, but I have some very important information for you, could you please stop what you are doing and deal with it”. The processor then drops everything, handles the interrupt (by calling the interrupt handler for that interrupt, which is a small chunk of code designed to be triggered by that interrupt), and then goes back to what it was doing.

The interrupt handling functionality is very low-level, and mostly implemented in hardware (some interrupts are even triggered by changing voltages on the external pins of the processor, and the others by a low-level processor instruction) so it is very robust against higher-level software screwing up. Even if your OS is stuck in an infinite loop, or in a deadlock, or merrily overwriting itself due to a buffer overflow, the interrupts will still work, and so long as the interrupt handling code is still good, the mouse/keyboard/&c will still work.

It’s kind of like how in humans some low-level reflexes don’t go through the brain at all, so they still happen in people with severe brain injuries.

8

Damn, so I’m doomed to be clicking through a field of frozen tabs forever??! I wish there was some way around this, cause I really like opening a bunch of tabs and reading through them all slowly

9

Just get a better computer :slight_smile:

10

Does it also have to do with the low level connection between drivers and the kernel that allow things like keyboard, mouse & video to continue working when other code goes kaput?

11

Yup.

12

It also helps that modern computers compartmentalize many of their tasks. A crash, glitch, or error in one program can freeze that program, but the others are unaffected. That’s why crashing your browser often doesn’t affect a program playing music in the background, for instance. The mouse-cursor program is so simple, so small, and so old and refined as to be almost uncrashable, while your browser is much bigger, more complicated, and newer, so it’s less refined and more likely to crash.

13

Another interesting thing is this:
Modern Operating Systems are designed so that each program runs in it’s own memory space. That way, if one goes crazy, it doesn’t step all over another’s memory, and corrupt it. That makes BSOD (or in OS X, Kernel Panics) very rare. However, it’s still possible to lock up the entire system, by crashing some very important low-level routine, like the I/O subsystem, or network I/O. If this happens, the machine will be essentially unusable, but the Mouse and Video systems will work just fine, because they don’t depend on those routines.

14

If the cursor is still moving in response to the mouse, then most of the computer is probably still working fine, but your graphical user interface is stuck.

15

Your computer isn’t frozen. It’s just stuck in some process looping forever, or waiting for an event that never happens. Lot’s of stuff keeps happening and there are a lot of event responses like cursor movement. It may be processing TCP messages the whole time also. If you open the Task Manager you may be able to stop the problem application or process and free up the system. Often things will come back after some time. Some default timeouts are pretty long.

16

Certainly in recent times the mouse pointer was provided by a hardware sprite driven by mouse events read by an interrupt routine. The mouse handler is a pretty low-level function as it needs to be small and quick as it gets called so frequently.

Because the hardware sprite is generated by the video hardware it can normally still update the video display even if things are pretty messed up and because the input routine is so small & tight there’s normally room for it to get some CPU time. And as somebody up thread alluded to, the main OS kernel is generally still working but the display/window manager is hung.

17

Speaking of playing music, that reminded me of this interesting example about events and loops in windows:

I have a utility program I wrote myself in vb6 to compare two similar samples of text and show me the first difference between them. I didn’t build in proper thread handling, so while it’s working hard on two nearly-identical samples, it’s not responding to any events or even redrawing its own window.

On my work computer, I have a special play-pause key that will automatically control windows media player even if that program isn’t the top window.

However, if the compare program is the top window, it’s busy, and I hit the pause button, the music won’t stop. I can manually click on windows media player, pause it - and once the compare program is finished the comparison it was working on, it’ll finally relay that ‘play/pause button event’ to windows media player, and it starts up again! :smiley:

18

For Windows, a more complete answer is that:

[ul]
[li]User-mode threads run at IRQL = PASSIVE_LEVEL (IRQL = 0 on x86)[/li][li]Thread rescheduling is done at IRQL = DISPATCH_LEVEL/DPC_LEVEL (IRQL = 2). Often, it is invoked as a Deferred Procedure Call (DPC).[/li][li]Normal hardware device Interrupt Service Routines (ISRs) operate at IRQL = device IRQL (DIRQL). (IRQL = 3-26 decimal)[/li][li]The real time clock ISR operates at IRQL = CLOCK_LEVEL (IRQL = 28).[/li][/ul]

The catch is that when the system is at a given IRQL, it cannot be interrupted to do work of equal lesser IRQL. In other words, when the IRQL is above DISPATCH/DPC_LEVEL, thread rescheduling cannot occur. It does not matter how high you set the thread priority, it will not even be scheduled to run a core until at least one core in the system is running at IRQL < DISPATCH/DPC_LEVEL. Furthermore, any threads scheduled for execution won’t actually run until IRQL = PASSIVE_LEVEL (or APC_LEVEL in the case of some kernel mode threads).

Because of this, kernel mode software tries to run below DISPATCH/DPC_LEVEL as much as possible. When the clock ISR fires, it is running at CLOCK_LEVEL, which not only blocks thread rescheduling, but also blocks device drivers. This is not a good condition, so the only thing it does at this level is to update some kernel timers and counters, and check if rescheduling needs to occur. If it does, the clock ISR makes a deferred procedure call to the scheduler, and exits as early as possible. The rescheduling (picking the best thread to run next) will happen whenever the IRQL drops to (or through) DISPATCH/DPC_LEVEL.

Similarly, device drivers try to as little work as possible at DIRQL level. For instance, a USB controller is going to take the data it reads from the bus and stuff it in a memory buffer somewhere, and do whatever bare minimum is needed to acknowledge receipt so that the controller can continue its operation. Actually processing that data will generally be deferred by a DPC to some other function of the driver.

Whenever you move your mouse, it transmits data on the USB bus (we’ll assume that’s what you have). The USB controller picks up this data and generates a hardware interrupt. The driver is invoked at DIRQL, which is greater than DISPATCH/DPC_LEVEL. Eventually, the USB driver will identify this data, and pass it off to the mouse driver. The mouse driver will update a kernel structure in memory representing the mouse position, register mouse clicks for synchronization objects (programs waiting for click events) and make some function calls to the window manager (aero in Vista/Win 7, GDI in Win XP) to redraw the mouse cursor. All of this will likely be done in a deferred procedure call, which runs at DISPATCH/DPC_LEVEL.

Here’s the point: mouse movement is more resistant to freezes because it is handled by code running at DISPATCH/DPC_LEVEL at the behest of code invoked at DIRQL level. Suppose that some buggy device driver is queuing up an excessive number of DPCs. This blocks thread rescheduling entirely until the queue is emptied. However, it won’t (probably) block DIRQL level interrupts, so the mouse driver is still able to inject its own DPCs into the queue. The result is that user applications freeze, but the mouse can still be moved around.

Other OSes have different architectures, and I’m not sure this exact behavior would occur on either Mac or Linux. Linux allows user mode processes running as root (UID=0) to make a system call which lowers the I/O privilege level, granting direct hardware access from user mode. Thus the X server (windowing environment) runs as a normal user mode process. If something gets tied up in the kernel, the mouse driver kernel module may still continue to function, but the X server won’t be able to respond to it.

Mac OS is derived from BSD and the Mach 3 kernel. This is a microkernel architecture which takes things even further than Linux. I’d wager that the mouse driver in Mac is a regular user process, but then, so is just about everything else. Having not used Mac myself, I can’t say how that makes things play out.

19

Because mice are warm-blooded.

20

That’s due to the design of Windows specifically. The top-most window gets keypresses by default*. If your program is frozen, it’s not processing window messages (in Windows, “not processing window messages” is pretty much the exact definition of “frozen”), so your program isn’t doing anything with those incoming keyboard messages, but since it has priority over other windows, it’s also not passing them along to another window that might want a whack at them.

The solution is to thread your program properly, you lazy bum. :wink:

*) Note that this is not true of some Linux distros, where inactive windows can react to the keyboard if the mouse is over them. Go figure.