Windows 95’s ticking death

A few years ago, Larry Osterman explained the famous beeping death. Windows 95 had its own noise-related death, what nobody has called ticking death, but that's what I'm going to call it. (Let's see how long before somebody decide to add it to Wikipedia.)

When your machine fell into ticking death, each time you moved the mouse or pressed a key, it was acknowledged with nothing more than a tiny click from the speaker. What was the cause of ticking death?

When the hardware drivers report a mouse or keyboard event on Windows 95, they call the mouse_input or keybd_input function. Since this happens at hardware input time, those functions are very limited in what they can do. All they do is appends the new input to a queue of "input that arrived while I was busy doing something else." When the window manager reaches a stable state, it takes the input from the "input waiting to be processed" queue and farms them out to the appropriate application input queues. The window manager needs to be stable, since mouse input gets routed depending on which window is under the mouse pointer when the pointer moves, and you don't want to do this while some other part of the window manager is in the process of rearranging the windows (and the window tree is consequently unstable).

For compatibility reasons, the window manager promises not to change anything while 16-bit code is running, so that a 16-bit application doesn't see, for example, a window becoming destroyed behind its back. (Recall that 16-bit Windows is a co-operatively multi-tasked system, which means that applications have control of the CPU until they voluntarily relinquish it.)

If a 16-bit application hangs, then the buffer for holding all of these "distribute this input to application queues as soon as it is safe to do so" fills up and can't accept any more input. If new input arrives and there's nowhere to save it, the window manager emits a little tick sound as a mini-error message.

Of course, as the end user, you probably knew something was up because the screen hasn't changed in a long time. Some 16-bit application is not responding and is preventing the window manager from doing anything. To get out of this situation, you can hit Ctrl+Alt+Del and try to kill the hung application.

Comments (24)
  1. pietje says:

    Funny that the mouse still moved in this failure mode. I always had to terminate “winoldap” processes but I don’t remember things returning to normal after terminating everything (systray and explorer last).

    Very often the screen was blank while this happened and the 32×32 square the cursor sits in showed up.

    [Not funny at all if you think about it: Imagine if the mouse moved only when a program pumped a message. You’d have a herky-jerky mouse all the time, and once the hourglass went up, the mouse would freeze. -Raymond]
  2. Pierre B. says:

    As worded, you seem to say that this is limited to Windows 95, but my Windows XP at hope sometimes freezes at the welcome screen and when it does, hitting keys on the keyboard eventually leads to the beeping feedback you describe. I suppose the code is still alive and well, even today.

    (Interestingly enough, the freezes occur only if I use the friendly login screen. With the classic one where you need to enter both your name and password, the computer never freezes on startup. I keep the friendly version for my sons. I really shoudl reinstally XP one day…)

    [I can assure you that it’s not the same code even if the symptoms appear the same. The Windows 95 beeping death code is written in 16-bit assembly language. -Raymond]
  3. Mark (The other Mark) says:


    If you are hearing a beep when hitting a key, you are probably overflowing the keyboard buffer. The beep is coming from BIOS, not from Windows. Essentially, BIOS is waiting for something to check for keyboard input, but nothing is. After 16(?) keystrokes, the buffer is full and you get a beep letting you know the keystroke was not added to the buffer.

    The beeping code, in this case, doesn’t even belong to MicroSoft.

    16 may or may not be an implementation detail of the BIOS, an industry standard, or a figment of my imagination. I’m not sure the size would matter if you know how to fill it and how to read from it, at least not to me.

  4. Koro says:

    @Mark: The BIOS keyboard handling code does not run anymore once Windows takes over.

  5. Alexandre Grigoriev says:

    The other Mark,

    When Windows 95 is working, the BIOS keyboard handler is pretty much out of pucture. VMM has its own keystroke buffer. It also intercepts the DOS session BIOS requests.

  6. Mark (The other Mark) says:

    Mmm. It would appear that I was mistaken. I was under the impression that the BIOS Buffer was active and handing the keystrokes to the windows buffer.

    Ah, well, I was wrong, but at least I learned something.

  7. Dan Hallock says:

    The sound itself is the same tick as the keyboard overflow sound, isn’t it? I always assumed the two were related (as a user, they both give the impression of “too confused to accept further input”).

  8. Chris L says:

    Wow, I remember this! It sounded like a Geiger counter when you moved the mouse around.

  9. Hi, Raymond.

    I’m thrilled to have discovered your blog. To see that you’re still sharing nuggets about Windows 95 brings back great memories of the early days when I learned *so much* from your participation in the Microsoft newsgroups, from your first TweakUI effort, and even from the occasional private communication (when I held the lofty title of MVP! :-)) . My next move after clicking "Submit" will be to buy your book!

    If I may suggest a blog topic to the world’s premier repository of Explorer arcana, I’ve been very curious to know whether the fact that the Windows Vista and Windows 7 versions of Explorer (and by extension of any program that uses standard TreeView controls, such as Regedit) no longer differentiate the "open folder" and "closed folder" icons was a deliberate decision by the shell team or an oversight when designing the icon resources in shell32.dll.  I thankfully learned a workaround from TweakUI’s "remove the shortcut arrows" feature, but I remain curious about the "decision", if that’s what it was.


  10. cha0s says:

    I have had this since Windows 95 (XP in my case3, too) so I don’t know why you insisted to the last guy that it couldn’t have happened.

    [You’re suffering from technology hypochondria, assuming that identical symptoms imply identical causes. -Raymond]
  11. ulric says:

    Because not every case that uses MessageBeep is the problem that is being discussed here.

    That would be like saying that every problem that shows an error message box on screen is the same problem.

    The problem discussed here is the very specific one that happened in Windows 95 the system was blocked and you moved the mouse and it would tick-tick-tick-tick rapidly with each mouse move.  You knew you were screwed when that happen. Sometime it came back Ok, sometime you never got back the control of your machine

  12. Some guy says:

    So was this fixed somehow in Windows 98? Or did it have the same behavior?

  13. TechMaster says:

    Windows 95 did not fully take over from BIOS, as the BIOS keystroke delay rate would still function. If the mouse made the clicking noise, it was Windows. If it was the keyboard, it was your BIOS keyboard buffer overflowing.

    Speaking as someone still running two Win95 boxes for older gaming and one is doing this at this very moment.

  14. WndScks says:

    @Some guy: No, Win98 did this also

  15. Falcon says:

    @TechMaster: I believe the typematic function is performed by keyboard hardware (in the keyboard itself, not the PC). Software like BIOS and Windows drivers can send commands to the keyboard to set the keystroke repetition delay and rate.

    Also, IIRC, it took a lot more keystrokes (in the absence of mouse moves, at least) to fill the queue when Windows was running than under DOS/BIOS.

  16. Mentifex says:

    Although the Amiga is my mentally ingrained computer, unfortunately I am using a Windows 95 computer to develop MindForth artificial intelligence with a dependency on open-source Win32Forth. Even though the weird things described here happen now and then, I am actually quite happy with the stability and robustness of Windows 95. I bought the computer second-hand for only twenty-nine ($29.00) dollars, after reluctantly switching from the Amiga to Windoze when made me an offer I could not refuse: a free Windows 98 machine that they gave away 40,000 of before they went bust. And Windows 98 was crashing a lot more than Windows 95 does. Great blog post.

  17. Dan says:

    Mentifex:  Is it first edition or the second (98SE).  I seem to recall 98SE being far more stable.

  18. Stephen Jones says:

    —–"I seem to recall 98SE being far more stable."—–

    It was; and then they brought ME along to trash their own reputation.

  19. Mentifex says:

    Commenter Dan above asks whether

    gave away 40,000 Windows 98 machines with the first edition or the second edition. I never knew. actually wanted to include Windows 2000, but they had to go with Windows 98 to get their product out the door. Recipients of the Free PC’s had to tolerate an L-shaped area of advertisements on their Compaq Presario screen. The computer broke down within a couple years, and the monitor lasted about ten years. Next I am thinking of buying an Acer Aspire netbook with Windows XP (home edition). Then maybe I will be able to log onto SourceForge again and claim back the AI project that was (IMHO) hijacked away from me. -Arthur

  20. Brian Peppers says:

    I love it that you are a total expert on this stuff and have even written a book about it and there are STILL people commenting about how "no, you are wrong, let me explain it to you with my wild guesses wholly unbacked by any kind of research or evidence."


  21. Marc says:

    I always remember Windows 98 being stable, right up until IE 5.5(!)

    And yes I remember the ticking. I remember it through my 3D "multimedia speakers" :)

  22. Frederik Slijkerman says:

    So how do modern Windows versions cope with this? Do they change the window state behind the back of 16-bit applications, or do they employ another trick?

  23. Paul says:

    “To get out of this situation, you can hit Ctrl+Alt+Del and try to kill the hung application.”

    Wait, wasn’t the input queue filled with requests at that time, so you just get a beep for every attempt to get the task manager showed? Or is CTRL+ALT+DELETE routed through a different mechanism?

    [Given that it does work, one might conclude that Ctrl+Alt+Del is handled at a lower level than Windows input queue message distribution. After all, DOS apps don’t have an input queue; what happens to their input? -Raymond]
  24. @Frederik Slijkerman

    Modern 32-bit Windows effectively runs a 16-bit app inside a virtualised fake version of 16-bit Windows (Windows on Windows or "WOW"). Calls to the 16-bit USER APIs get translated into calls to the 32-bit window manager, which is in a separate protected process and so isn’t affected if an app hangs up.

    By default 16-bit apps share the same host process (and so if one hangs or trashes memory, all other 16-bit apps are affected), but you can configure them to run in their own isolated process, so they effectively get their own instance of 16-bit windows to run in.

    None of this applies in 64-bit Windows, which doesn’t support 16-bit apps. (However, it does reuse the initials WOW to described support for 32-bit apps).

    Windows 3.1 actually had a 32-bit kernel that supported multi-threading and process isolation, and the process of switching over to 32-bit drivers for things like file system and networking began with Windows for Workgroups, but there was only so far it could go – the aim was for it to run Office in 4 MB of RAM, so they kept the 16-bit Window Manager and used a single critical section to serialise all access to it from 32-bit threads.

    The combination of a 386-based kernel with the 16-bit Windows GUI code, which lasted as the world’s mainstream GUI OS until XP came out, was a pretty amazing achievement, given the constraints. Like the dancing bear, don’t try to be impressed by the quality of the dancing, just marvel that it can dance at all.

Comments are closed.