DEVICE_QUEUE_NOT_BUSY (0x00000002): Meaning and Windows Troubleshooting

Quick Answer

DEVICE_QUEUE_NOT_BUSY is a Windows stop error, also called bug check 0x00000002. It tells you which condition caused Windows to stop, but the code alone does not tell you which device, driver, or other component was responsible. Microsoft’s page for this particular bug check provides no universal repair; it directs programmers to investigate the crash with the !analyze debugger extension. learn.microsoft.com

If the computer restarted once and works normally, record the error and monitor it. If the crash repeats, note when it happens, check recent hardware and driver changes, install applicable updates, and examine a crash dump if the basic checks do not identify the cause. The steps below explain what each check can reveal and when to involve an IT professional. support.microsoft.com

What DEVICE_QUEUE_NOT_BUSY means

A Windows stop error occurs when the system encounters a condition serious enough to shut down or restart. The screen may show the stop code and, sometimes, a filename after “What failed.” Save both details if they appear. The filename can help guide an investigation, but it still needs to be checked against the crash evidence. support.microsoft.com

Despite the word queue in the name, this code does not by itself indicate a printer-queue problem. Microsoft lists it as a Windows bug check and does not assign it a printer-specific cause or repair. learn.microsoft.com

Before changing anything: collect the basic facts

For an intermittent problem, a short record is often more useful than trying several fixes at once. Note:

• The exact stop code and any “What failed” filename.
• The date and time of each crash.
• Whether it occurs during startup, sleep or wake, a particular application, or use of an external device.
• Hardware, driver, Windows, firmware, or software changes made shortly before the first crash.
• Whether the machine restarts successfully and how often the error recurs.

Make one targeted change at a time, then check whether the same activity still triggers the crash. This helps you tell which action made a difference. If the computer contains important files, confirm that you have a usable backup before taking recovery steps that could affect data, apps, or settings. Microsoft cautions that some Windows recovery options can cause data loss. support.microsoft.com

Troubleshoot a computer that still starts

1. Check recent hardware changes

If the crashes began soon after connecting or installing hardware, shut down the computer and disconnect or remove that recently added device where it is safe and practical to do so. Restart and test the activity that previously caused the crash.

If the crashes stop, you have a useful lead, not final proof. Check the device manufacturer’s compatibility and driver guidance before reconnecting it. Avoid disconnecting an internal component unless you are equipped to work on that computer safely. Removing newly added hardware is among Microsoft’s basic stop-error troubleshooting steps. support.microsoft.com

2. Inspect Device Manager

Right-click Start and open Device Manager. Look for a device with a warning symbol, especially one associated with a recent change. Open its properties and note any device-status message.

A warning symbol provides a specific issue to investigate. The absence of one does not rule out a driver problem. If a relevant device is identified, check Windows Update or the device manufacturer for an appropriate driver. Avoid installing drivers from unrelated download sites. Microsoft includes Device Manager checks in its stop-error guidance. support.microsoft.com

3. Revisit a recent driver update

If the problem began immediately after a particular driver update, open that device’s Properties > Driver tab in Device Manager and check whether Roll Back Driver is available. If you use it, restart when prompted and test again. The button may be unavailable when Windows has no previous driver version to restore. support.microsoft.com

Do this for a driver connected to the timing or evidence of the crash. Reverting unrelated drivers makes the result harder to interpret.

4. Install applicable Windows updates

Open Settings > Windows Update, check for updates, install applicable updates, and restart if requested. Then test the computer under the same conditions in which it previously crashed. Windows Update is part of Microsoft’s general stop-error troubleshooting guidance. support.microsoft.com

5. Review events around the crash

Open Event Viewer and inspect the Windows Logs > System entries around the recorded crash time. Look for preceding device or driver errors, not merely an entry saying that the computer restarted unexpectedly. An event close to the crash is a clue to correlate with other evidence; timing alone does not prove causation. Microsoft recommends checking the System log for related errors when troubleshooting stop codes. support.microsoft.com

If these checks do not reveal a cause and the crashes continue, move to crash-dump analysis rather than repeatedly changing unrelated settings.

If Windows will not start reliably

Use Safe Mode to investigate a recent driver or software change when normal startup repeatedly fails. From the Windows Recovery Environment, the documented path is Troubleshoot > Advanced options > Startup Settings > Restart, then select the appropriate Safe Mode option. The exact route into the recovery environment depends on whether you can reach the sign-in screen. support.microsoft.com

Once in Safe Mode, focus on the change that immediately preceded the crashes. For example, inspect an affected device in Device Manager and roll back its driver if that option is available. Restart normally to verify whether the change helped. If startup still fails, consult Microsoft’s recovery options and choose the least disruptive option appropriate to the situation. Back up important files before a recovery operation that may remove data, apps, or settings. support.microsoft.com

Crash-dump analysis for IT professionals

A memory dump captures information about the system at the time of a crash. An IT professional can open it in WinDbg and use the !analyze extension to investigate the bug check. This is more informative than searching for a fix based only on 0x00000002. Microsoft notes that effective dump analysis may require experience with Windows debugging and system internals. learn.microsoft.com

Locate or configure a dump

Check whether a dump was created for the crash. Small memory dumps are normally kept under %SystemRoot%\Minidump; the configured dump type and location can be reviewed in System Properties > Advanced > Startup and Recovery > Settings. The available controls and wording can vary by Windows version. A small dump contains limited information, so it might not expose a cause outside the activity captured at the time of the crash. Windows Client

If no useful dump exists, an administrator can review Write debugging information in Startup and Recovery and select a suitable dump type for future crashes. A setting change cannot recreate a dump for a crash that has already happened. Larger dump types require more storage and may contain more sensitive data. Follow your organization’s rules when storing or sharing crash dumps. Windows Client

Analyze the actual crash

Open the dump in WinDbg and run:

!analyze -v

Review the reported bug-check code and parameters, stack, loaded modules, and any suspected component. Compare the findings with the crash time, System events, and recent changes. If the analysis names a driver, establish its version, publisher, associated device, and relevance before deciding to update, roll back, or escalate it. A name appearing in a report is an investigative lead, not a complete root-cause finding. Microsoft documents opening crash dumps in WinDbg and using !analyze for bug-check investigation. learn.microsoft.com

The command !analyze -show 0x2 displays information about bug-check code 0x2. It does not substitute for analyzing the affected machine’s dump with !analyze -v. learn.microsoft.com

How to judge whether the issue is resolved

After a targeted change:

1. Restart the computer if the change requires it.
2. Repeat the activity that previously preceded the crash, when it is safe to do so.
3. Check whether the stop error returns during normal use.
4. Record the change and the observation period.

An intermittent crash may take time to recur. If DEVICE_QUEUE_NOT_BUSY returns, keep the new crash time and dump so the cases can be compared. If several devices show errors, the computer cannot produce a useful dump, or the analysis points to an unfamiliar driver or hardware path, escalate with the collected evidence.

Frequently asked questions

Is DEVICE_QUEUE_NOT_BUSY always a driver problem?

No. The code-specific Microsoft page does not identify one universal cause. Windows stop errors in general can involve hardware, drivers, or software, so use the surrounding evidence to narrow the cause. learn.microsoft.com

Does 0x00000002 prove that a device has failed?

No. It identifies the bug check, not a confirmed failed component. Avoid replacing hardware solely because of the name of the error. learn.microsoft.com

Why can’t I find a minidump?

A dump may not be present or the computer may be configured to write a different dump type. Check Startup and Recovery settings and the configured location. Dump creation can also fail under some crash conditions; an empty folder by itself does not establish the cause of the original stop error. Windows Client

Should I use Driver Verifier?

Driver Verifier is an advanced diagnostic tool for controlled driver investigations. It can deliberately trigger further crashes when it detects driver violations. Do not turn it on as a routine first step on a computer you need to keep available; have an experienced administrator assess whether it is appropriate after reviewing the existing evidence. learn.microsoft.com

Should I reinstall Windows?

A reinstall is not a code-specific fix and may leave a hardware-related problem unresolved. Work through the targeted checks and review any available dump first. If recovery is needed, read the effects of the selected option and back up important files. learn.microsoft.com

Conclusion

DEVICE_QUEUE_NOT_BUSY (0x00000002) tells you which Windows stop error occurred, but it does not tell you what to replace or which driver to remove. Record the circumstances, investigate recent changes, perform targeted checks, and analyze a crash dump if the error repeats. The most useful fix is the one supported by evidence from the affected computer.

Sources

• Microsoft Learn, Bug Check 0x2: DEVICE_QUEUE_NOT_BUSY. learn.microsoft.com
• Microsoft Support, Troubleshooting Windows unexpected restarts and stop code errors. support.microsoft.com
• Microsoft Support, Update drivers through Device Manager in Windows. support.microsoft.com
• Microsoft Learn, Advanced troubleshooting for stop code errors. learn.microsoft.com
• Microsoft Learn, Read small memory dump files. Windows Client
• Microsoft Learn, Bug check code reference. learn.microsoft.com
• Microsoft Support, Recovery options in Windows. support.microsoft.com