IOHIDEventQueue error resulting in long Mac pauses

Various I/O errors can cause pauses in Mac systems, and one of these may show errors in the system console that contain "IOHIDEventQueue" warnings.

A familiar type of computer error is the kind in which all activity seems to freeze, there's no apparent response to keyboard input, and the mouse stops moving. When this happens on Macs you may see the spinning color wheel, or the system may show no indicator of a problem. While you might think the system has fully crashed and needs to be restarted, a few seconds later the system may continue to function normally again, only to pause again shortly thereafter.

This type of random pausing is generally due to an I/O (input/output) problem. Critical devices that are either polled for input or that are supplying a stream of input to the computer will often hang up for various reasons, and when this happens the entire system may pause while it waits for the expected data.

When I/O errors occur, many times the system service that is managing the data will output error messages to the system console, so opening up the Console utility and selecting "All Messages" should show some indication of the I/O error. This may be a message from the kernel, or from a low-level daemon process (the name of which will usually end in with a "d," such as "diskarbitrationd" for the disk arbitration daemon).

One of the most common reasons for this error is if the hard drive or another storage device on the system is not working properly. If a drive is going bad and developing bad blocks , when the system runs into these blocks then it will pause while it waits for the expected data. In the case of hard-drive errors, if restarting and formatting do not fix the problem then replacing the hard drive may be the only way to address the issue, especially if the drive is progressively developing bad blocks or otherwise showing signs of failure.

Another type of I/O error that may happen and cause intermittent pausing will display output in the console similar to the following:

9/14/11 10:15:10.366 PM hidd: IOHIDEventQueueEnqueue: Error enqueuing memory. (e00002e8)
9/14/11 10:15:10.370 PM hidd: IOHIDEventQueueEnqueue: Error enqueuing memory. (e00002e8)
9/14/11 10:15:10.370 PM hidd: IOHIDEventQueueEnqueue: Error enqueuing memory. (e00002e8)
9/14/11 10:15:10.371 PM hidd: IOHIDEventQueueEnqueue: Error enqueuing memory. (e00002e8)
9/14/11 10:15:10.371 PM hidd: IOHIDEventQueueEnqueue: Error enqueuing memory. (e00002e8)
9/14/11 10:15:10.371 PM hidd: IOHIDEventQueueEnqueue: Error enqueuing memory. (e00002e8)
9/14/11 10:15:10.371 PM hidd: IOHIDEventQueueEnqueue: Error enqueuing memory. (e00002e8)

In this instance, the process "hidd" is having trouble with a specific function call not properly managing the memory it was called to manage. That the error repeats numerous times in a few milliseconds also indicates it is an I/O error because the same event is attempted repeatedly but is not getting anywhere. In most applications when errors occur the program will terminate, crash, or (if programmed to do so) purposefully change its execution to accommodate its inability to run properly; however, many times I/O processes will try the same function repeatedly while the program waits for the expected data, resulting in the same error being output rapidly.

In OS X the hidd process is the "human interface device daemon," which is responsible for managing a subclass of input devices that are designed for human interaction, and therefore have buttons, switches, knobs, or touch pads on them. Examples of these are USB keyboards, mice, and track pads, and also the system's power and reset buttons.

In the case of hidd devices, I/O errors happen because in order to prevent a system process from missing any input, when a button is held down the system will queue the input so it can be fed to an active process as it loops through its functions. If the process pauses for any reason, then the queued inputs will be available for it when it starts back up again. This is why if your system is lagging and you drag a window across the screen, the window movement may continue to the desired point at a slower speed than your initial dragging movement. In this case the high CPU usage of the system slows down the processes managing the inputs, so the inputs build up and the system grabs them more slowly instead of picking them up in real time.

Related links
• Fix pauses in OS X by correcting bad blocks
• Fixing printer setup problems in OS X
• Thunderbolt gearing up to stick around

The hidd daemon manages these queues for keyboard and pointer inputs, and stores the queued input sequences in memory for applications to use. In the I/O console errors above, the daemon is trying to load the inputs into memory but cannot, which could be for any number of reasons, such as a driver error, conflict with multiple input devices, or a hardware malfunction in a specific device.

Generally, if this problem happens it will continue to happen until you restart the system, so your best bet for fixing it in the short term is to simply restart your computer. Most times a restart will be enough to clear the problem. If it recurs then try troubleshooting your various input devices, especially those that are attached directly to your system, such as USB or FireWire devices. If the problem persists, especially if it occurs immediately after restarting, then try replacing the input device with another one to see if that helps. When troubleshooting peripherals in this manner, unplug all additional peripheral devices (printers, modems, and so on), and also consider trying different USB ports on the system to see if the port configuration is a contributing factor.

With some systems this specific problem can happen rarely enough that it may be difficult to troubleshoot in this manner, and so it will probably be easiest to simply restart the system and continue without further troubleshooting.

Questions? Comments? Have a fix? Post them below or e-mail us!
Be sure to check us out on Twitter and the CNET Mac forums.

About the author

    Topher, an avid Mac user for the past 15 years, has been a contributing author to MacFixIt since the spring of 2008. One of his passions is troubleshooting Mac problems and making the best use of Macs and Apple hardware at home and in the workplace.


    Join the discussion

    Conversation powered by Livefyre

    Show Comments Hide Comments