What does Windows error code 1119 (ERROR_IRQ_BUSY) mean?

 
Previous Next
ERROR_SERIAL_NO_DEVICE ERROR_MORE_WRITES

ERROR_IRQ_BUSY

Unable to open a device that was sharing an interrupt request (IRQ) with other devices.

ERROR_IRQ_BUSY is Win32 error 1119 (0x45F). It records a resource conflict in which a device sharing an interrupt request could not be opened because another device on that IRQ was already active in an incompatible way.

Modern and legacy relevance

The wording reflects hardware models in which devices used fixed or shareable line-based interrupts. Modern PCIe devices often use message-signaled interrupts and ACPI resource assignment, but 1119 can still matter for legacy buses, industrial adapters, old serial or parallel controllers, firmware-emulated devices, and virtual machines that reproduce older resource rules.

  • ISA or legacy PCI cards with manually configured IRQ jumpers or firmware settings
  • multi-function adapters whose drivers disagree about interrupt sharing
  • virtual hardware mapped to the same emulated interrupt line
  • a custom driver that rejects sharing or fails to connect its interrupt correctly

Diagnostic evidence

  • the failing device instance and the other devices assigned the same interrupt resource
  • raw and translated resource lists reported to the driver
  • Device Manager resource view, problem code, driver version, and firmware version
  • whether the conflict appears only after one specific device is opened first
  • hypervisor or BIOS settings that control legacy interrupt routing

Record the order in which devices are started and opened. An ordering-dependent failure is a strong clue that two drivers claim a shared resource differently or that one driver leaves the interrupt configured after close.

Investigation steps

  • confirm that the code originates from the device-open path rather than a generic application wrapper
  • compare the assigned resources on a working and failing machine
  • update or roll back the specific device and chipset drivers in a controlled test
  • move an add-in card or change a virtual-device slot only when the platform supports resource reassignment
  • use kernel debugging or driver traces when a third-party driver mishandles interrupt connection or teardown

Do not disable unrelated devices permanently just to make the symptom disappear. That can confirm a conflict, but the production fix should establish a supported resource layout or corrected driver behavior.

Handling

An application cannot repair an IRQ conflict with a normal retry. It should report the device identity and stop attempting high-frequency opens until device configuration changes. Administrators should schedule firmware, slot, or driver changes because they can affect boot-critical hardware.

Driver developers should support interrupt sharing when the bus and hardware permit it, validate that the interrupt belongs to their device before claiming it, and release resources symmetrically on stop and removal.

Related results

ERROR_SERIAL_NO_DEVICE means no serial device initialized and can be a downstream consequence of resource assignment failure. ERROR_BUSY is a generic busy-state code and does not specifically identify interrupt sharing. Device Manager problem codes often provide more actionable PnP context than 1119 alone.

Example

A legacy data-acquisition card and an onboard serial controller are both routed to the same emulated IRQ in a VM. Whichever device opens first works; opening the second returns 1119. Capturing the virtual slot and interrupt map proves that the application is not the cause, and assigning a supported virtual resource layout resolves the conflict.

References

Looking for a different code? Search another status or error code.