The Old New Thing

That explains it. Earlier this year my Sony Viao started having a freeze up problem. It was everything - including the mouse. I scanned for spyware, viruses anything I could think of. Found nothing. It wasn't until it was late one night and it was really quiet that I could hear the hard drive re-reading the same area over and over. Put in a new HD, and it never did it again. I thought this was strange that it would cause a lockup like that since you would think that the mouse would still work while the HD was trying to re-read the drive.

Similarly, the NumLock key can indicate just how locked up your system is.

My story comes from a video card pooping out. The mouse didn't freeze per se - it was jittery. Slow, steady movements of the mouse would result in fast+stop jumps across the desktop. In my case I was able to run Process Explorer to see 'DPCs' get small junks of time at the same time the mouse would jitter. A quick google search turned up DPC's being a hardware failure. So several hours later doing safe-mode boots enabling devices one at a time finally started jittering when the video driver was installed. Updating the driver didn't help. Dell replaced the video card and viola!

Well, DPCs aren't "a hardware failure", I don't think.  DPCs are the way the kernel does interrupt-related work from a non-interrupt context.  Since interrupt handlers can't do a lot of work (e.g., they can't sleep, so they can't take locks, and there's generally a limit on how long they can take to execute because they run with interrupts disabled), they generally just grab the required data out of the device (or the DMA region that the device copied it to), queue it somewhere, and set up a DPC to do the rest of the processing.

(NICs, for instance, generally work like this.  When they get a received-frame indication from the hardware, which usually means the NIC has DMA'ed a frame into a buffer somewhere, they copy it out of the buffer and queue a DPC.  The DPC, which runs in a non-interrupt context, handles the rest of the frame-receipt logic -- e.g. giving the frame to NDIS, and from there to user-space.)

So getting DPCs isn't an indication that your hardware is failing.  However, getting a lot more DPCs than normal, or having DPCs take a long time to process, may be.  (It may also just be a broken driver, although it wasn't in your case.)  Lots of DPCs just means you're getting lots of interrupts, which may be caused by the driver telling the device to retry over and over again because each retry fails.  Or they may be caused by e.g. a lot of stuff that looks like network traffic but isn't (especially if you use a software driven wireless card).

I'm puzzled by your description of the origin of the WM_MOUSEMOVE messages:  I don't think I've seen the behavior I'm about to describe on the WinNT flavors, but it was very common on Win9x and before.

On Win9x, if you experienced a significant crash of the system, sometimes the only way that you would know for certain that the system was dead was that you'd waggle the mouse around for a while, and then suddenly the PC's internal speaker would start clicking loudly, one click for what seemed to be every motion the mouse made.  It did this for the keyboard, too, but not for anything else that generated interrupts (network, audio cards, timers, etc.).  Sometimes the cursor would move, sometimes it wouldn't:  But the clicks were a dead giveaway that the system was toast and the only option you had left was the Big Red Switch.

I always took this to assume that the system had some sort of internal message queue that had filled up with a few hundred low-level "mouse move" messages and that it was "beeping" to indicate that the queue was full and not being serviced.  This seemed especially true since it seemed to require about the same number of input messages after a crash to cause it to happen.

Further, I've seen times on Win9x where an app suddenly received not one "spurious" WM_MOUSEMOVE messages, but dozens or hundreds of them, in effect "catching up" to its correct state from when the system was "sleepy".  I've even seen my own apps do that when the system got overloaded, and I know for a fact that I don't have any sort of secondary queuing mechanism in those.

I can't remember seeing the same behavior on any of the WinNT flavors, although that doesn't necessarily guarantee anything.

Now, if, as you say, the Win9x window manager were just setting a flag every time an interrupt fires, you wouldn't expect to see either of the two behaviors described above.  So what's the real story here?  Was Win9x's window manager implemented significantly differently than NT?  Quirky drivers?  Side-effects of having the old Win16 code in there?  This obviously doesn't affect any software anybody writes today, but I'm really curious as to why that old legacy mouse-move behavior seemed contrary to what you said here.

Alternate explanation for why doesn't the cursor move with the mouse:  Filthy Mouse.

Crud on the ball or internal rollers for the mechano-optical type or little bit of something, as small as half an inch of a single hair, stuffed up in the hole over the light receiver on a true optical mouse, and so forth.

[A bunch of work happens before that bit gets set since you have to compute which thread's bit to set. Hardware input is queued into the raw input thread and the raw input thread does the work. The beeping means that the raw input thread queue is full. I ignored this implementation detail since it wasn't relevant to the discussion. -Raymond]

Okay, so there *is*, in fact, one more lower-level input queue involved at the stage of "The mouse hardware notifies the window manager, 'Hey, I moved left twenty units.'"  I find this to be a significant detail only because there's no requirement that any sort of queuing happen at that stage for it to work correctly.  The mouse driver could simply fire off an interrupt that says, "Hey, I changed," and all that interrupt does is raise an Event somewhere, and then the window manager would then later notice the Event and query the mouse about its *current* state.  This may sound like a weird way to do it, especially since an intervening input change could be lost, but that's how a *lot* of video game consoles handle their input, so it's not really as weird as it sounds.

So one last question, and then I'll let this drop:  How large is (was) the low-level input queue?  I realize this is an implementation-dependent detail, but I'm mainly curious because I could never seem to perfectly count how many messages there were before the clicking started.  It was somewhere between 100 and 1000, I think, but I could never quite nail it down.

The beeping issue is interesting, because I get similar behavior on my XP box, specifically when I run a specific game (GZDoom if you must know).

Sometimes, when it starts, it doesn't seem to take input, and I hear beeps when I press a key or move the mouse. After a while it "catches up" and a blur of motion is seen on the screen, presumably the input that was "missed" earlier.

So, this definately is an application issue, yet it causes the beeping which occurs at a very low level. Any guess as to what is going on?

I've had the clicking-sound-on-mouse-and-key-input-while-frozen in Windows 2000 several times, especially when working on one particular program which disagrees with the VS2005 debugger (though I don't know why) - it occasionally gets in a state where the whole computer mostly-freezes after breaking/stepping in the debugger, and Windows appears to process one input message (mouse movement, click, key press) every ten seconds or so. If I wiggle the mouse enough, it's presumably hitting the same queue limit, and it starts beeping. (That sound always makes me very nervous, like I'm overtightening a clockwork toy and the spring is about to break, though I can reason on a logical level that it's not going to do anything bad.)

Unfortunately my heart is too faint to try debugging the cause of the problem - depending on how much I feel like working, I either hit the 'stop debugging' button as soon as possible and wait half a minute until it reacts, or else sit back and relax and wait a few more minutes until it unfreezes itself and carries on debugging happily. I particularly like 6-minute games of Zoo Keeper on the DS during those breaks, which is probably why I never get as much work done as I would like...

Guess I can't quite let it drop, since I apparently wasn't clear last time.

[You can't do hit-testing at hardware interrupt time.]

I know that; and I wasn't suggesting that the processing might have been moved more toward the interrupts, but rather the other direction.  The interrupt would be basically a three-line chunk of code that sets a flag saying the mouse's status changed, and then the interrupt handler would leave all the remaining details of figuring out *what* changed --- of pulling the data from the mouse and actually dealing with it --- to some other thread.  That's a perfectly reasonable way to handle input processing, and the difference would've been nearly invisible to the end-user.  In that scenario, no queue is required --- just a flag.  But some events could be lost, since the mouse doesn't get queried for its data immediately after the interrupt fires.  Compare the pseudocode:

Method #1:

Mouse Interrupt:

  PostInternalInputMessage(QueryMouse())

  ret

Window manager thread:

  WaitForSingleObject(internal input queue)

  switch (event) {

  case MOUSE:

      mouse_state = ComputeNewMouseState(event.mouse_deltas)

      hwnd = FindWindow(mouse_state)

      PostMessage(hwnd, mouse_state)

  }

Method #2:

Mouse Interrupt:

  mouse_deltas += QueryMouse()

  SetEvent(mouse_has_input)

  ret

Window manager thread:

  WaitForMultipleObjects(various input events)

  if (mouse_has_input) {

      mouse_state = ComputeNewMouseState(mouse_deltas)

      mouse_deltas = 0

      hwnd = FindWindow(mouse_state)

      PostMessage(hwnd, mouse_state)

  }

See the difference?  Method #1 is how Windows does it, more-or-less.  In method #2, there's no input queue, and none is required, because the data aggregates by itself at each interrupt; the window manager only needs to collect the data and reset it each time it "notices" something happened.  Method #2 (or something like it) is used for a variety of input devices on other hardware, and was a semi-popular way of handling button-state-changes on the GameBoy Advance, among other consoles (a lot of developers preferred polling, but some developers used the interrupt too).

[The internal hardware queue in Windows 95 was 100 events.]

That's quite a bit shorter than I would've guessed.  You must've had pretty fast processing to keep that from overloading.  I was thinking it was in the 500-ish ballpark.  *shrug*

[You owe me 15 minutes of my life. -Raymond]

I'll consider it an even trade for the time I've spent tracing bugs through USER, GDI, and KERNEL. :P

[Doing it your way means that the input manager can lose things like the mouse button being pressed and released in rapid succession if the raw input thread doesn't process the events fast enough.]

Yes, and it wouldn't be the first time that inputs on computer equipment got lost because they were typed/pressed/sent too quickly; both old and new software and hardware have suffered from this for a variety of reasons.  My point was that some other systems handle input processing that way, so it was a viable option to consider when trying to work out how the window manager treated these things.  I didn't claim it was the end-all be-all of input-processing solutions:  Only that it couldn't be ruled out without additional knowledge of the implementation of the window manager.  Which you've now provided.

(And, in fact, it's a rather poor way to handle input, but it works surprisingly well in many cases.  You don't necessarily need a "big" solution like a long queue to handle input:  The GameBoy Advance and Nintendo DS both use polling for their input, and the Apple II computers had a keyboard-input queue that was exactly one entry deep.)

[quote]

ots of DPCs just means you're getting lots of interrupts, which may be caused by the driver telling the device to retry over and over again because each retry fails.  Or they may be caused by e.g. a lot of stuff that looks like network traffic but isn't (especially if you use a software driven wireless card).

[/quote]

For another possible reason, our company recently got hitted by Viking worm, and noted an exceptionally high (> 60%) CPU time devoted to DPCs. Likely because the worm is trying the passwords of other machines' share.

There is another much simpler thing that can happen so that your mouse doesn't move -- broken PS/2 or USB cable.

You can twist it a bit and the mouse starts moving again. I usually throw such mice away and buy a new one but they can be fixed.

It is actually easy, open the mouse and disconnect the cable from the printed circuit board. There are four wires in the cable and they usually break near the entrance into the mouse casing so it is easy to figure out which one is broken by pulling on them one by one until one of them comes out of the cable. Next you have to cut the cable at the appropriate place and solder the wires directly to the PCB. It helps if you have vacuum (suction) pump to remove the connector and clear the holes, even better if you have spare pins and crimping tool. The only important thing is not to mix the wires but since they are colored it is hard to make a mistake.

As for the software side of the problem, I was always astonished by Windows inability to keep GUI responsive regardless of what happens in the system. It amazes me that even though you have all that protective stuff in place one program can still bring the system to its knees or kill it alltogether.

From user perspective, unresponsive GUI is the worst experience in computing especially if you want to multi-task and you have another intensive task running. Not to mention that you can choke Windows to death if you make it start swapping.

Raymond, I seem to remember an message you sent many years ago that involved a twitch game that called into the keyboard interrupt handler from the timer interrupt handler to do what Shawn is suggesting.

It was a bad idea back in the Win9x days, it's still a bad idea.

> What does it mean if the cursor doesn't move at all when you move the mouse?

It means that on some corner on your desk, a wayward stylus has somehow managed to roll onto your Wacom tablet, locking the mouse position to that precise spot.

Yes, it's happened to me.

Sean: Mice don't use two way communication. The mouse just sends Δx, Δy and the button states to the computer when there's a change. I suppose it could be different in the case of usb mice, but those are a recent wrinkle, and frankly I've never seen a mouse that had any reason to accept input from the computer.

Another reason to queue mouse events may be graphics programs. Assuming I'm not as horribly mistaken as I opften am.

I recommend a slow, cpu-intensive interpreted GUI language on a slow machine for this experiment. Create something basic: a white gui panel that draws lines between each mousemove event.

If you wiggle your mouse, you get (after several seconds dalay as it slowly draws) the line drawn prettymuch as you drew it, rather than just between the start point and end point. You do not need to build a per-application event queue.

In the days of Dos, many graphics apps would do the straight-line thing instead. I think some early windows apps did this too, though, so it may not be related and I may be talking nonsense.

>Similarly, the NumLock key can indicate just how locked up your system is.

Unless you happen to have a "Microsoft Internet Keyboard", which turns on/off Numlock even when the computer is frozen ("I bet someone got a raise for that"). Caps/Scroll lock still wait until the computer responds, though.

>and frankly I've never seen a mouse that had any reason to accept input from the computer.

I guess you haven't seen a force feedback mouse, then.

[frankly I've never seen a mouse that had any reason to accept input from the computer.]

I think that a mouse probably won't need to get any input regarding it's movement (a direct reply), but I can think of many ways a mouse may need to acquire some set of data from the computer.

Erzengel mentions force feedback, and another example is my wireless Logitech mouse. It needs to receive commands from the mouse software, in addition it has indicators for IM/email notifications (that don't work with Outlook or MSN Messenger even though the box clearly says it does--marketing and engineering not talking with each other I suppose).

I have exactly the described problem when I open a folder with the explorer. But only with my Administrator account. My normal User account works perfecly well.

I took FileMon to see what happens when ever I open a folder:

16   0.00013242   explorer.exe:3152   OPEN   F:\01 System - Anwendungen

WinXP\Tools\7Zip\desktop.ini   FILE NOT FOUND   Options: Open  Access: All

17   0.00001928   explorer.exe:3152   QUERY INFORMATION   F:\01 System -

Anwendungen WinXP\Tools\7Zip   SUCCESS   Attributes: D

18   0.00011677   explorer.exe:3152   OPEN   F:\01 System - Anwendungen

WinXP\Tools\7Zip   SUCCESS   Options: Open  Access: All

19   0.00002123   explorer.exe:3152   READ    F:\01 System - Anwendungen

WinXP\Tools\7Zip   INVALID DEVICE REQUEST   Offset: 0 Length: 24

20   0.00005531   explorer.exe:3152   OPEN   F:\01 System - Anwendungen

WinXP\Tools\7Zip\:{4c8cc155-6c1e-11d1-8e41-00c04fb9386d}:$DATA   FILE NOT

FOUND  Options: Open  Access: All

21   0.00003604   explorer.exe:3152   OPEN   F:\01 System - Anwendungen

WinXP\Tools\7Zip\:SummaryInformation:$DATA   FILE NOT FOUND   Options: Open

Access: All

22   0.00003436   explorer.exe:3152   OPEN   F:\01 System - Anwendungen

WinXP\Tools\7Zip\:Docf_SummaryInformation:$DATA   FILE NOT FOUND   Options:

Open Access: All

If I open the same folder with my user account I get no erros, everything works fine.

I haven't found out yet what causes the explorer hangs. Any ideas?

AIM does a global mouse hook in order to count idle time on the system.  I assume other messengers do likewise, though I haven't investigated them in quite so much detail.  Do these not count as low-level hooks?  (Also, I feel rel. secure that a fair number of games do low-level mouse hooks, but those probably don't count as normal for you.)

Speaking of DPC floods, it sure would be nice if there were some way of determining what's queueing all those DPCs without having to hook up a kernel debugger! Every so often I'll wake up my laptop and some device is using up 30% of the CPU with DPCs.

Of course that behavior makes the fan turn on, which makes the battery die even faster, and it cannot be put back to sleep or hibernated, so shutting down is the only way to make it stop. If I knew what piece of hardware/software was causing this, I might be able to figure out how to prevent it in the future.

What about applications that "lock" the cursor by calling SetCursorPos(const,const) on each WM_MOUSEMOVE? As far as I see, this is the most common approach for games to make sure that the they always get relative movements. If such a window is active and for some reason didn't make the cursor invisible, you can see a cursor that jitters some pixels, but doesn't actually move away.

There's another way to lock up the mouse, though: get a REALTIME_PRIORITY_CLASS process with some high-priority threads (I'm not sure exactly how high they need to be) and put one of the threads into an infinite busy-loop.  Instant mouse-death.

I *believe* the reason for this is that the mouse handling is done by csrss, and its threads are lower priority than realtime, so if a realtime process is sapping all your CPU then they don't get to run and you don't get any mouse movement.

> A flaky hard drive can have the same effect.

> If the window manager itself takes a page

> fault, it has to wait for the hard drive to

> page in the data. and if the window manager

> happened to be holding a lock when this

> happened, that lock is held across the entire

> I/O operation.

Then the same effect can occur even when the hard drive is in pristine condition.  For me this has been a common occurence shortly after awakening from hibernation but not shortly after an ordinary boot (but hibernation is still faster and preferable for lots of reasons).  Now I understand why tons of hard disk accesses can cause this effect, thank you.  I still think there are more possible reasons though.

Friday, November 17, 2006 4:22 PM by Sean W.

> On Win9x, if you experienced a significant

> crash of the system, sometimes the only way

> that you would know for certain that the

> system was dead was that you'd waggle the

> mouse around for a while, and then suddenly

> the PC's internal speaker would start

> clicking loudly, one click for what seemed to

> be every motion the mouse made.  It did this

> for the keyboard, too,

Happens on Windows XP too.  The funny thing is that sometimes Windows XP recovers from this condition, though 9x never did (at least not in my experience).  If it happens after all of the apps have entered non-responding mode then Windows XP doesn't recover from it.

Vista seems to have a change here.  After all of the apps enter non-responding mode then Ctrl+Alt+Del plus a wait might bring up an error message about inability to start the task manager instead of just hanging.  I don't recall hearing those clicks from Vista.

[Raymond Chen:]

> As for the USER, GDI, and KERNEL bugs, I'm

> pretty sure I didn't create the bug and then

> ask you personally to investigate it.

Sean W.'s message is still visible, and he didn't create the mouse event queue and then ask you personally to investigate it, he merely narrated his guess that the size was between 100 and 1000.  Your decision to investigate was a far more voluntary decision than his was.

"\"\\\"So one last question, and then I'll let this drop: How large is (was) the low-level input queue?\\\"\""

Sorry, my mistake.  I owe you 5 minutes.

You can ameliorate this to some extent by setting  HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\DisablePagingExecutive to 1, this consumes a bit more memory but also ensures that Windows will never have to wait to page in bits of itself from disk.

> [Windows needs to page more than code.

> There's also data. -Raymond]

http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/29931.mspx?mfr=true

says:

*  * Tip

*  Setting this value to 1 is useful when

*  debugging drivers, because all of the code

*  and data is always memory resident.

OK, it doesn't quite say that all of the code and data is always memory resident even when not debugging drivers, but it's pretty close.  I think I've redeemed the 5 minutes I owed you.

If you have a wireless mouse, it may just be that it needs new batteries.  

We know get this often as for some reason Dell ships wireless mousse/keyboards on desktops introducing unnecessary points of trouble, and leading to more support calls etc.

>>Similarly, the NumLock key can indicate just how locked up your system is.

>Unless you happen to have a "Microsoft Internet Keyboard", which turns on/off Numlock even when the computer is frozen ("I bet someone got a raise for that"). Caps/Scroll lock still wait until the computer responds, though.

I don't think that's specific to Microsoft keyboards - an old Compaq keyboard of mine exhibits the same behaviour - thus confusing me for some time when an driver upgrade kept locking up CSRSS with an infinite loop in a DPC.

I noticed that the mouse pointer easily gets stuck (or at least very jittery) if you have pointer shadow enabled, or if you use color (not black-and-white) pointers, and the machine is under heavy load.

> No wait, I don't wonder because I don't care.

I have no complaint about your cynicism.  It is well earned.  But now I wonder, when you complained about my cynicism, where were your complaints coming from?

(You are under no obligation to answer.  You can leave me wondering.)

"Our slogan is: you can talk when you need!Thare is no problem what we can not solve."

"frankly I've never seen a mouse that had any reason to accept input from the computer"

Just wait to see this one:

http://www.razerzone.com/Products/Gaming-Mice/Razer-Diamondback-Gaming-Mouse/

It has firmware updates too.