Bug Check 0x00000128: WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY – Causes and Troubleshooting Guide

Quick Answer

WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY (Bug Check 0x00000128) is a Windows Blue Screen of Death (BSOD) error that occurs when a worker routine incorrectly modifies the I/O priority of a Windows worker thread and returns control without restoring the expected priority state.

Windows uses worker threads to perform background operations, including tasks associated with device drivers and system components. When a worker routine violates the expected I/O priority state, Windows detects the inconsistency and generates a bug check to protect system stability.

This error is primarily associated with incorrect kernel-mode driver or worker-routine behaviour. However, the exact offending component cannot be identified from the stop code alone.

To investigate the problem, examine the Windows crash dump using WinDbg, identify the worker routine and associated driver, and investigate recently installed or updated drivers. Update, roll back or remove the identified problematic driver where appropriate.

What Is WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY?

WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY is a Windows kernel bug check with the hexadecimal value 0x00000128.

Windows uses worker threads to execute background tasks that are queued by different operating system components and device drivers. These threads allow the system to perform operations without requiring every task to execute directly in the context of the original requesting thread.

During certain operations, a worker routine may temporarily modify the I/O priority associated with its worker thread. The routine is expected to maintain the required priority state and restore it appropriately before returning.

If the worker routine returns while the I/O priority has been incorrectly modified, Windows detects the violation and stops the system.

This bug check is a kernel-level consistency check. It does not simply indicate that a storage device is slow, that disk usage is high, or that a particular drive has failed.

Understanding I/O Priority

I/O priority determines the relative priority assigned to certain input/output operations. It helps Windows manage competing I/O requests and allocate system resources appropriately.

For example, a computer may perform several I/O operations simultaneously:

• Reading and writing application data.
• Accessing system files.
• Performing background maintenance operations.
• Loading data required by device drivers.
• Executing storage-related background tasks.

Windows uses I/O priority mechanisms to help manage these operations. A worker routine that improperly changes the priority state can violate an internal operating system requirement.

What Causes Bug Check 0x00000128?

Microsoft documents the direct condition behind this bug check: a worker thread's I/O priority was incorrectly modified by the worker routine that was called.

However, Microsoft's public bug check documentation does not provide a definitive list of consumer-level root causes. The actual component responsible must be identified through debugging evidence.

The following are investigation areas rather than confirmed causes of every 0x00000128 crash.

1. Faulty or Incompatible Device Drivers

A kernel-mode driver that incorrectly manages worker-thread operations may violate Windows kernel requirements.

Drivers associated with storage controllers, device management, security software and other system-level components may be relevant investigation targets when they appear in the crash stack.

A driver should not be considered responsible merely because it appears in the list of loaded drivers. Its relationship to the failing worker routine must be established through dump analysis.

2. Recently Updated or Installed Drivers

A BSOD that begins after a driver installation or update may indicate a compatibility or implementation problem.

Investigate recent changes involving:

• Storage controller drivers.
• NVMe, SATA or RAID controller drivers.
• Chipset drivers.
• Third-party device drivers.
• System-level security or monitoring software.

These components are investigation candidates, not a confirmed list of drivers responsible for this specific bug check.

3. Third-Party Kernel-Level Software

Some applications install kernel-mode components to interact with hardware, monitor system activity or provide additional functionality.

Examples include certain endpoint security products, antivirus software, disk management utilities and hardware monitoring tools.

If the crash started after installing or updating such software, examine its associated drivers and check whether the vendor has released a compatible update.

4. Driver Compatibility Problems

A driver developed for a different Windows version, hardware platform or configuration may not behave correctly in the current environment.

Compatibility problems should be investigated when the BSOD occurs after:

• Upgrading Windows.
• Installing a major Windows feature update.
• Replacing hardware.
• Installing an OEM driver package.
• Changing storage controller configurations.

5. Driver or Kernel Memory Corruption

Incorrect memory handling by a kernel-mode component can sometimes cause unexpected system behaviour.

Although the documented 0x128 condition specifically concerns worker-thread I/O priority, additional dump analysis may reveal other driver errors or corruption that contributed to the failure.

Memory corruption should not be assumed without supporting debugging evidence.

Symptoms of WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY

When this bug check occurs, Windows stops normal operation and displays a Blue Screen of Death.

Common observable symptoms include:

• Unexpected system restart.
• Blue Screen displaying the stop code WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY.
• Stop code value 0x00000128.
• Repeated crashes during normal Windows operation.
• Crashes occurring after installing or updating a driver.
• System instability following a hardware or software configuration change.

The exact circumstances depend on the worker routine and component involved. There is no single application or activity that universally triggers this error.

Understanding Bug Check 0x00000128 Parameters

Microsoft documents four parameters for the WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY bug check.

These parameters provide information that can help developers and technicians identify the worker routine responsible for the violation.

Parameter	Description	Diagnostic Purpose
Parameter 1	Address of the worker routine.	Can be examined using the WinDbg ln command to identify the associated symbol or driver.
Parameter 2	Current I/O priority value.	Provides the I/O priority value associated with the bug check.
Parameter 3	Work item parameter.	Provides the parameter associated with the queued work item.
Parameter 4	Work item address.	Provides the address of the work item associated with the operation.

Why Are These Parameters Important?

The parameters are particularly useful when investigating a crash dump using Windows Debugger (WinDbg).

Parameter 1 is especially important because it identifies the address of the worker routine. The debugger's ln command can help resolve this address to the nearest available symbol and assist in locating the potentially offending driver.

Parameters 2, 3 and 4 provide additional information about the I/O priority and associated work item.

These values should be interpreted together with the call stack, loaded modules and other debugging information. They should not be treated as independent proof of a particular driver failure.

How to Troubleshoot WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY

Because this bug check identifies an internal worker-thread priority violation, the most useful troubleshooting approach is to investigate the crash dump and identify the component responsible.

Follow the steps below, starting with the safest diagnostic procedures.

Step 1: Identify When the BSOD Started

Before modifying drivers or Windows configuration, determine when the problem first appeared.

Check whether the crash started after any of the following events:

• Installing a new device driver.
• Updating an existing driver.
• Installing third-party security software.
• Installing disk or storage management utilities.
• Performing a Windows update.
• Replacing or upgrading hardware.

If the problem appeared immediately after a specific change, record that information. It can help narrow down the investigation.

Do not uninstall multiple drivers or applications simultaneously because doing so makes it difficult to identify the actual cause.

Step 2: Check Windows Crash Dump Files

Windows can generate memory dump files when a system bug check occurs. These files contain diagnostic information that can help identify the component involved in the crash.

For this error, examining the crash dump is one of the most useful troubleshooting procedures.

Check the following locations:

• C:\Windows\Minidump\ – Contains small memory dump files, when configured and successfully generated.
• C:\Windows\MEMORY.DMP – Common default location for kernel, active, automatic or complete memory dumps.

Look for dump files created around the time of the BSOD.

If the Minidump folder is empty, Windows may not have generated a dump file, or the dump configuration, paging file or storage conditions may have prevented its creation.

Step 3: Configure Windows to Generate Memory Dumps

If Windows is not generating useful crash dumps, check the system failure and recovery settings.

1. Press Windows + R.
2. Type sysdm.cpl and press Enter.
3. Open the Advanced tab.
4. Under Startup and Recovery, select Settings.
5. Locate the Write debugging information section.
6. Select Automatic memory dump or Kernel memory dump when appropriate.
7. Verify that the dump file path is configured correctly.
8. Check that sufficient disk space is available.
9. Click OK to save the settings.

For more detailed kernel debugging, a kernel or automatic memory dump is generally more useful than a small dump because it contains additional information.

Important: Windows requires suitable paging-file or dedicated dump-file configuration to generate the selected type of memory dump. Do not arbitrarily disable the paging file while troubleshooting crash dumps.

Step 4: Analyze the Crash Dump Using WinDbg

WinDbg is Microsoft's debugging tool for examining Windows crash dumps and investigating kernel-level failures.

It can display bug check information, driver modules, symbols, memory information and kernel call stacks.

Procedure:

1. Install WinDbg from the official Microsoft distribution.
2. Launch WinDbg.
3. Select the option to open a dump file.
4. Browse to the relevant .dmp file.
5. Wait for the dump to load and symbols to initialize.
6. Enter the following command in the debugger command window:

!analyze -v

This command performs a detailed analysis of the current bug check.

Examine the output for:

• BUGCHECK_CODE – Confirms the bug check value.
• BUGCHECK_P1 through BUGCHECK_P4 – Displays the four bug check parameters.
• MODULE_NAME – Identifies a module associated with the analysis, when available.
• IMAGE_NAME – Provides the image name associated with the reported module, when available.
• STACK_TEXT – Displays the relevant kernel call stack.
• Probably caused by – Provides the debugger's suspected component, if it can determine one.

Important: A debugger's probable-cause identification is an investigative lead, not conclusive proof. Correlate it with the worker routine address, call stack, symbols and other available evidence.

Step 5: Identify the Worker Routine Using Parameter 1

Microsoft specifically recommends using the ln (List Nearest Symbols) debugger command on Parameter 1 to help find the offending driver.

In WinDbg, obtain the value of Parameter 1 from the bug check output or the .bugcheck command.

Then execute:

ln <Parameter1_Address>

Replace <Parameter1_Address> with the actual hexadecimal address reported for Parameter 1.

The command attempts to identify the nearest available symbol associated with the supplied address.

For example, a symbolic result may identify a function belonging to a particular kernel module or driver.

If the address resolves to a third-party driver, investigate that driver's version, vendor, compatibility and recent update history.

If symbols are unavailable or the address cannot be resolved reliably, configure the correct Microsoft symbol path and repeat the analysis.

Note: Do not assume that a driver is faulty simply because it appears in the crash dump. Confirm its relationship to the worker routine and failing execution path.

Step 6: Update or Roll Back the Identified Driver

Once the dump analysis provides a reasonable indication of the responsible driver, check whether an updated or corrected version is available.

Use the device manufacturer's official support website or the relevant hardware vendor's driver distribution channel.

To update a driver through Device Manager:

1. Right-click the Start button.
2. Select Device Manager.
3. Expand the category associated with the identified device.
4. Right-click the relevant device.
5. Select Update driver.
6. Follow the available update instructions.

For systems that use manufacturer-specific driver packages, prefer the computer or motherboard manufacturer's recommended package when appropriate.

If the crash began immediately after a driver update, consider rolling back the driver:

1. Open Device Manager.
2. Locate the affected device.
3. Right-click it and select Properties.
4. Open the Driver tab.
5. If available, select Roll Back Driver.
6. Follow the instructions and restart Windows if required.

The Roll Back Driver option may be unavailable if Windows does not have a previous driver version available.

Step 7: Remove Recently Installed Problematic Software

If the crash started after installing third-party software that includes kernel-level drivers, investigate that software.

Examples include certain antivirus products, endpoint protection tools, disk utilities and hardware monitoring applications.

Recommended procedure:

1. Open Windows Settings.
2. Navigate to Apps > Installed apps.
3. Identify recently installed software that may be related to the failing driver.
4. Check for a vendor update or compatibility advisory.
5. If necessary, uninstall the suspected application using its official uninstallation procedure.
6. Restart Windows and monitor system stability.

Before removing security or endpoint protection software from a business computer, coordinate with the IT administrator and ensure that an appropriate security solution remains in place.

Step 8: Install Available Windows Updates

Windows updates may contain operating system improvements, driver compatibility changes and reliability fixes.

To check for updates:

1. Open Windows Settings.
2. Navigate to Windows Update.
3. Select Check for updates.
4. Review available updates.
5. Install applicable updates from trusted sources.
6. Restart the computer if required.

For enterprise computers, follow the organization's update management policy before installing updates on production systems.

Installing updates is a general maintenance recommendation, not a guaranteed fix for bug check 0x128.

Step 9: Check System Stability After the Changes

After updating, rolling back or removing a suspected driver, restart the computer and observe whether the issue returns.

Check the following:

• Whether Windows starts normally.
• Whether the original activity still triggers the crash.
• Whether new BSOD events occur.
• Whether new crash dump files are generated.
• Whether the same worker routine or driver appears in subsequent dump analysis.

If the crash disappears after a specific driver change, that change provides useful evidence. However, repeatable testing and dump comparison are preferable before concluding that the issue is permanently resolved.

Advanced Troubleshooting for IT Professionals

If the basic troubleshooting procedures do not identify the responsible component, advanced kernel debugging may be necessary.

1. Examine the Kernel Call Stack

The kernel call stack shows the sequence of function calls active when the bug check occurred.

In WinDbg, use:

!analyze -v
kv
k

The kv and k commands display call-stack information in different formats.

Examine the stack for the worker routine and associated driver modules. Correlate the results with Parameter 1 and the debugger's symbol information.

A stack trace can provide valuable evidence, but an incomplete or corrupted dump may prevent reliable identification.

2. Examine the Bug Check Parameters

To display the bug check code and its parameters in WinDbg, use:

.bugcheck

Verify that the reported code is 0x00000128 and record all four parameters.

Compare Parameter 1 with the worker routine information and examine the remaining parameters as part of the overall investigation.

3. Use Driver Verifier Only When Necessary

Driver Verifier is a Windows diagnostic utility designed to test driver behaviour and detect certain driver programming violations.

It can help investigate difficult driver-related crashes, but it is an advanced troubleshooting tool rather than a routine first step.

Driver Verifier can introduce additional system crashes, significantly affect performance and prevent Windows from starting normally when a driver fails verification.

Before using Driver Verifier:

• Back up important data.
• Ensure that you have access to Windows Recovery Environment.
• Understand how to disable Driver Verifier if Windows cannot start normally.
• Identify the specific third-party driver that needs investigation.
• Avoid enabling verification indiscriminately across all drivers.

Driver Verifier should be used by experienced technicians or driver developers who understand the recovery procedure.

For additional information, refer to Microsoft's Driver Verifier documentation.

4. Compare Multiple Crash Dumps

If the computer experiences repeated BSOD errors, compare multiple dump files instead of relying on a single crash.

Look for recurring patterns such as:

• The same worker routine address or symbol.
• The same third-party driver appearing in relevant call-stack frames.
• Similar bug check parameters.
• Repeated crashes after the same system operation.
• A consistent relationship with a recent driver or software change.

Repeated evidence can help distinguish a recurring driver problem from an isolated system failure.

What If Windows Cannot Boot Normally?

If the 0x128 BSOD occurs during startup or creates a restart loop, use Windows Recovery Environment to access recovery options.

Depending on the Windows version and available recovery configuration, the following procedures may help:

1. Enter Windows Recovery Environment

If Windows fails to start repeatedly, Windows Recovery Environment (WinRE) may load automatically.

Alternatively, use Windows installation or recovery media to access the recovery environment.

Navigate to:

Troubleshoot > Advanced options

2. Try Startup Settings and Safe Mode

From Advanced options:

1. Select Startup Settings.
2. Select Restart.
3. After restarting, choose the appropriate Safe Mode option.

Safe Mode starts Windows with a limited set of drivers and services. It may allow you to investigate or remove a recently installed problematic driver or application.

Safe Mode does not guarantee that every kernel-level driver issue can be bypassed.

3. Use System Restore When Appropriate

If a restore point was created before the problem started, System Restore may help revert certain system changes.

Access Troubleshoot > Advanced options > System Restore and follow the instructions.

Review the affected programs and drivers before confirming the restoration.

System Restore is not a replacement for a proper backup and does not guarantee recovery from every driver-related failure.

How to Prevent WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY

Although prevention cannot be guaranteed, good driver and system maintenance practices can reduce the likelihood of recurring driver-related system failures.

1. Use Compatible Device Drivers

Install drivers intended for the exact hardware model and supported Windows version.

Prefer official manufacturer sources and avoid installing unverified driver packages.

2. Maintain Windows Updates

Install relevant Windows updates according to your system's update policy. Updates can provide important operating system and compatibility improvements.

3. Avoid Unnecessary Kernel-Level Utilities

Install only trusted software that requires low-level system access. Avoid unnecessary utilities that install multiple background drivers or modify system behaviour.

4. Maintain Driver Installation Records

For business and enterprise computers, maintain records of driver versions, installation dates and hardware changes.

This makes it easier to investigate whether a crash started after a particular deployment or configuration change.

5. Preserve Crash Dump Files

Keep relevant crash dumps until the underlying issue has been identified and resolved.

These files can be useful when comparing repeated crashes or requesting assistance from Microsoft or the hardware manufacturer.

Frequently Asked Questions (FAQs)

1. What does WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY mean?

It means that a Windows worker routine incorrectly modified the I/O priority of its worker thread and returned control without maintaining the expected priority state. Windows generates bug check 0x00000128 when it detects this violation.

2. Is error 0x00000128 related to a hard disk failure?

Not necessarily. Although the error involves I/O priority, it does not directly indicate that an HDD, SSD or storage device has physically failed. The actual problem must be investigated using crash dump analysis and driver information.

3. Which driver causes WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY?

There is no universally identified driver responsible for this error. Microsoft documents the incorrect worker-thread I/O priority modification as the direct bug check condition. Use Parameter 1, WinDbg symbols and the kernel call stack to investigate the associated worker routine and driver.

4. Can updating drivers fix BSOD 0x00000128?

Yes, updating or rolling back a driver may resolve the problem if the crash is caused by incorrect behaviour in that driver. However, driver changes should be based on investigation evidence rather than updating every installed driver indiscriminately.

5. What is the difference between error 0x00000128 and 0x00000129?

Both are Windows worker-thread I/O priority-related bug checks, but they identify different priority violations.

• 0x00000128 – WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY: Indicates that a worker thread's I/O priority was incorrectly modified.
• 0x00000129 – WORKER_THREAD_RETURNED_WITH_BAD_PAGING_IO_PRIORITY: Indicates that a worker thread's paging I/O priority was incorrectly modified.

6. Can Windows Memory Diagnostic fix error 0x00000128?

Windows Memory Diagnostic can help investigate certain RAM-related problems, but it is not a specific repair tool for this bug check. Use it when other symptoms or diagnostic evidence suggest a possible memory issue.

7. Is Driver Verifier recommended for this error?

Driver Verifier can help investigate driver programming problems, but it is an advanced diagnostic tool that may trigger additional crashes. It should only be used when necessary, with an appropriate recovery plan and preferably against a specifically identified driver.

8. Where can I find the crash dump for this BSOD?

Small memory dumps are commonly stored in C:\Windows\Minidump\. Larger kernel or automatic memory dumps are commonly stored in C:\Windows\MEMORY.DMP. The actual location depends on the system's crash dump configuration.

9. Does this error mean Windows needs to be reinstalled?

No. Reinstalling Windows is not the recommended first response. Investigate the crash dump, worker routine and associated driver before considering major operating system recovery procedures.

10. Can WinDbg identify the exact cause of this BSOD?

WinDbg can provide valuable diagnostic information, including bug check parameters, driver modules, symbols and call stacks. However, a debugger may not always identify the exact root cause, particularly when the dump is incomplete or the failure involves earlier memory corruption.

Key Takeaways

• 0x00000128 is the bug check value for WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY.
• The documented condition involves an incorrectly modified worker-thread I/O priority.
• Driver and worker-routine behaviour should be investigated before assuming hardware failure.
• Parameter 1 identifies the worker routine address and can be examined using WinDbg's ln command.
• The !analyze -v command provides detailed crash dump analysis.
• Update or roll back drivers only after identifying a relevant investigation target.
• Driver Verifier is an advanced diagnostic utility and should be used with caution.

The most reliable approach to resolving this BSOD is to identify the worker routine involved, examine its associated driver and use crash dump evidence to determine the underlying problem. Avoid assuming that the stop code alone identifies a particular hardware component or software package.

Official References

1. Microsoft Learn – Bug Check 0x128: WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY – Official description and bug check parameters.
2. Microsoft Learn – Stop Code Error or Bug Check Troubleshooting – Windows stop error troubleshooting guidance.
3. Microsoft Learn – !analyze (WinDbg) – Reference for the WinDbg crash analysis command.
4. Microsoft Learn – How to Read Small Memory Dump Files – Information about locating and examining Windows crash dumps.
5. Microsoft Learn – Varieties of Kernel-Mode Dump Files – Explanation of available Windows memory dump types.
6. Microsoft Learn – Driver Verifier – Advanced driver testing and verification documentation.