RESOURCE_NOT_OWNED is a Windows Blue Screen of Death (BSOD) stop error with the bug check value:

0x000000E3

It is also commonly displayed in debugging tools as:

RESOURCE_NOT_OWNED (E3)

According to Microsoft, this bug check occurs when a thread attempts to release a resource that it does not own.

This is primarily a kernel-level resource-management or synchronization problem. In practical troubleshooting, the underlying cause is frequently associated with a faulty or incompatible kernel-mode driver, although software conflicts, corruption, firmware problems, and unstable hardware should also be investigated.

The error may occur on:

• Windows 11
• Windows 10
• Windows Server
• Older supported or legacy Windows environments

A computer experiencing this problem may suddenly restart, display a blue screen, or create a crash dump without giving the user much warning.

RESOURCE_NOT_OWNED Technical Information

The stop code is:

Bug Check: RESOURCE_NOT_OWNED
Bug Check Code: 0x000000E3

The four bug-check parameters are used primarily during crash-dump analysis.

Microsoft defines them as follows:

Parameter	Meaning
Parameter 1	Address of the resource
Parameter 2	Address of the thread
Parameter 3	Address of the owner table, if one exists
Parameter 4	Reserved

These values are generally useful to developers and technicians analyzing the memory dump rather than ordinary Windows users.

Understanding What “Resource Not Owned” Means

Windows uses synchronization mechanisms to control access to shared kernel resources.

Imagine two kernel threads:

Thread A acquires access to a protected resource.

Thread A therefore becomes responsible for releasing that resource when its operation has finished.

If Thread B, which does not own the resource, attempts to release it incorrectly, Windows can detect an invalid resource-management condition.

Because this is happening inside the Windows kernel, continuing normal execution could result in corruption or unpredictable behavior.

Windows therefore stops the system and generates the RESOURCE_NOT_OWNED bug check.

Is RESOURCE_NOT_OWNED a Hardware or Software Problem?

It can potentially involve either, but drivers and kernel-level software should normally be investigated first.

Potential causes include:

1. Faulty device drivers
2. Incompatible drivers
3. Recently updated drivers
4. Kernel-mode software bugs
5. Storage or file-system filter drivers
6. Antivirus/security filter drivers
7. Backup software drivers
8. Virtualization software
9. Corrupted Windows components
10. Firmware or BIOS incompatibilities
11. Memory instability
12. Storage problems
13. Overclocking or unstable hardware
14. Third-party kernel utilities

Do not automatically replace RAM, SSD, motherboard, or other hardware simply because RESOURCE_NOT_OWNED appears.

Crash-dump analysis should ideally be performed first.

Common Causes of RESOURCE_NOT_OWNED

1. Faulty Device Driver

A defective kernel-mode driver is one of the most important possibilities to investigate.

Possible driver categories include:

• Storage drivers
• RAID drivers
• NVMe drivers
• SATA/AHCI drivers
• Graphics drivers
• Network drivers
• Wi-Fi drivers
• Bluetooth drivers
• USB drivers
• Printer drivers
• Security software drivers
• File-system filter drivers

A programming or synchronization error inside a driver can cause incorrect ownership or release of kernel resources.

2. Recently Updated Driver

If the blue screen started immediately after installing or updating a driver, that driver becomes a strong suspect.

For example:

Device Manager → Driver Update → Restart → RESOURCE_NOT_OWNED

In this situation, rolling back the recently installed driver may resolve the problem.

3. Old or Incompatible Driver

An older driver may have been designed for an earlier Windows build and may not behave correctly after Windows is upgraded.

This commonly becomes relevant after:

• Major Windows feature updates
• Windows 10 to Windows 11 upgrades
• Server upgrades
• Hardware replacement
• BIOS/UEFI updates

Always obtain critical drivers from the computer, motherboard, or device manufacturer's official support source where possible.

4. Security and Antivirus Software

Antivirus, endpoint-security, encryption, DLP, VPN, and backup applications may install kernel-mode drivers.

Examples include:

• File-system filters
• Network filters
• Disk filters
• Encryption drivers
• Endpoint monitoring drivers

If RESOURCE_NOT_OWNED began after installing or upgrading such software, investigate it carefully.

Do not permanently disable security protection simply as a workaround. Instead, update, repair, or replace the problematic component once identified.

5. Storage Drivers

Storage-related kernel drivers are another area worth examining.

This can involve:

• NVMe controller drivers
• SATA/AHCI drivers
• RAID controllers
• Storage filter drivers
• Backup software
• Disk encryption software
• Storage management utilities

If crashes occur primarily during large file transfers, backups, disk-intensive operations, or startup, investigate the storage stack.

6. Corrupted Windows System Files

Damaged system files can contribute to operating-system instability.

Possible reasons include:

• Interrupted Windows updates
• Unexpected shutdown
• Storage corruption
• Malware
• Failed upgrades
• Disk errors

Windows includes DISM and System File Checker tools that can repair many component and system-file problems.

How to Fix RESOURCE_NOT_OWNED

The following troubleshooting sequence is recommended.

Step 1: Restart the Computer

If RESOURCE_NOT_OWNED occurred only once, restart the computer and monitor it.

A single crash does not automatically prove that hardware has failed.

If the error occurs repeatedly, continue troubleshooting.

Step 2: Check What Changed Before the BSOD Started

Ask:

• Was a driver recently installed?
• Was Windows updated?
• Was new hardware added?
• Was antivirus software changed?
• Was backup software installed?
• Was virtualization software installed?
• Was BIOS updated?
• Was a storage driver changed?

If the problem started immediately after a change, investigate that change first.

Step 3: Install Windows Updates

Open:

Settings → Windows Update

Select:

Check for updates

Install appropriate updates and restart Windows.

Updates may contain fixes for Windows components, compatibility problems, and hardware support.

However, if the BSOD started immediately after a particular update, troubleshooting may instead require investigating or rolling back that change.

Step 4: Update Device Drivers

Pay special attention to:

• Chipset
• Storage controller
• NVMe
• SATA/AHCI
• Graphics
• LAN
• Wi-Fi
• Bluetooth
• USB
• RAID controller

Prefer drivers supplied by the system or hardware manufacturer when available.

Avoid downloading random drivers from untrusted “driver download” websites.

Step 5: Roll Back Recently Updated Drivers

Open:

Device Manager

Locate the suspected device.

Right-click it and select:

Properties → Driver → Roll Back Driver

Restart Windows.

This is particularly useful if the RESOURCE_NOT_OWNED error appeared immediately after a driver update.

Step 6: Remove Recently Installed Low-Level Software

Temporarily investigate software installed immediately before the crashes began.

Examples include:

• Third-party antivirus
• VPN clients
• Backup software
• Disk utilities
• Encryption programs
• Virtual-drive software
• Hardware monitoring utilities
• RGB/control utilities
• System optimization utilities

Simply closing such an application may not unload its kernel driver.

For troubleshooting, proper uninstallation may sometimes be required.

Step 7: Run System File Checker

Open Command Prompt or Terminal as Administrator.

Run:

sfc /scannow

Allow the scan to reach 100%.

Possible outcomes include:

Windows Resource Protection did not find any integrity violations

or

Windows Resource Protection found corrupt files and successfully repaired them

Restart Windows after repairs.

Step 8: Repair the Windows Component Store Using DISM

Open an elevated Command Prompt and run:

DISM /Online /Cleanup-Image /ScanHealth

Then:

DISM /Online /Cleanup-Image /RestoreHealth

After DISM finishes, run:

sfc /scannow

again.

Restart the computer.

Step 9: Check the File System

Run:

chkdsk C: /scan

For deeper repair where appropriate:

chkdsk C: /f

Windows may ask to schedule the check for the next restart.

Press:

Y

and restart.

Before performing disk repairs on an important business system, ensure that critical data is backed up.

Step 10: Test RAM

Memory instability can sometimes produce misleading crash symptoms.

Run:

mdsched.exe

Select:

Restart now and check for problems

Windows Memory Diagnostic will restart the computer and test memory.

For intermittent problems, technicians may also use extended memory-testing tools.

If multiple unrelated BSOD codes occur rather than RESOURCE_NOT_OWNED alone, RAM and general hardware stability become especially important to investigate.

Step 11: Disable Overclocking

Return the system to standard settings if any component is overclocked or undervolted.

This includes:

• CPU
• GPU
• RAM
• XMP/EXPO memory profiles
• Manual voltage settings

Load optimized/default BIOS settings when appropriate.

Do this carefully on business systems because changing storage-controller or boot-related BIOS options can prevent Windows from booting.

Step 12: Update BIOS/UEFI and Firmware

Check the manufacturer's support resources for updates to:

• BIOS/UEFI
• SSD firmware
• NVMe firmware
• RAID controller firmware
• Docking-station firmware

Firmware updates can improve hardware compatibility and stability.

Important: Never interrupt a BIOS or firmware update. Ensure stable power and follow the manufacturer's exact procedure.

Step 13: Perform a Clean Boot

A clean boot can help determine whether third-party services or startup software contribute to the problem.

Press:

Win + R

Enter:

msconfig

Under Services:

1. Select Hide all Microsoft services
2. Disable appropriate remaining third-party services for testing.

Then open Task Manager and disable unnecessary third-party startup applications.

Restart Windows.

If the problem disappears, re-enable items gradually to identify the conflicting software.

Step 14: Check Reliability Monitor

Press:

Win + R

and enter:

perfmon /rel

Reliability Monitor provides a timeline containing events such as:

• Windows failures
• Application crashes
• Driver failures
• Software installations
• Updates

Look for events immediately before the first RESOURCE_NOT_OWNED crash.

Step 15: Check Event Viewer

Open:

eventvwr.msc

Navigate to:

Windows Logs → System

Look around the crash time for warnings and errors involving:

• Disk
• StorPort
• NTFS
• WHEA
• Driver initialization
• Service failures
• Hardware problems

A common post-crash event may report that Windows restarted after a bug check.

Remember that Event Viewer often records consequences of a crash rather than the actual root cause.

The dump file is usually more valuable.

Finding the Windows Crash Dump

Windows may create crash dumps in locations such as:

C:\Windows\Minidump\

Individual files may look similar to:

082926-12345-01.dmp

A larger system dump may be stored as:

C:\Windows\MEMORY.DMP

These files can be analyzed using WinDbg.

How to Analyze RESOURCE_NOT_OWNED Using WinDbg

For repeated RESOURCE_NOT_OWNED crashes, dump analysis is one of the most useful diagnostic methods.

Open the dump in WinDbg and execute:

!analyze -v

Look for fields such as:

BUGCHECK_CODE
MODULE_NAME
IMAGE_NAME
FAILURE_BUCKET_ID
PROCESS_NAME
STACK_TEXT

For RESOURCE_NOT_OWNED, the analysis normally identifies:

RESOURCE_NOT_OWNED (e3)

The bug-check arguments contain information about the resource, thread, and owner table.

Do Not Automatically Blame ntoskrnl.exe

A dump may display:

ntoskrnl.exe

This does not automatically mean the Windows kernel itself is defective.

The kernel is responsible for handling fundamental operating-system operations and ultimately triggering the bug check.

A third-party driver may have corrupted state or performed an invalid operation before Windows detected the problem.

Therefore, examine the complete call stack and related modules.

Examining a Suspicious Driver

If the dump points to a driver such as:

exampledriver.sys

use WinDbg:

lmvm exampledriver

This can provide information such as:

• Driver path
• Module information
• Version information
• Vendor details
• Timestamp information

Then determine which application or device installed that driver.

Possible corrective actions include:

1. Update the associated software.
2. Update the driver.
3. Roll back the driver.
4. Repair the application.
5. Uninstall the problematic software.
6. Contact the hardware/software vendor.

Using Driver Verifier

Windows includes Driver Verifier for advanced driver troubleshooting.

Run:

verifier

Driver Verifier can place additional checks on kernel-mode drivers and may help expose defective driver behavior.

However, this tool should be used carefully.

Warning

Driver Verifier intentionally stresses drivers and can cause additional blue screens when a faulty driver is present.

It should preferably be used by experienced technicians and not casually enabled on a critical production computer or server.

Before using it:

• Back up important data.
• Ensure recovery access is available.
• Know how to enter Safe Mode.
• Know how to disable Driver Verifier.

To disable Driver Verifier, run from an elevated command prompt:

verifier /reset

Then restart Windows.

If Windows Cannot Boot Normally

Try entering Windows Recovery Environment.

Possible troubleshooting options include:

Troubleshoot → Advanced options

From there you may use:

• Startup Settings
• Safe Mode
• System Restore
• Uninstall Updates
• Command Prompt
• Startup Repair

If the problem is caused by a third-party driver, Safe Mode may allow you to remove or roll back it.

RESOURCE_NOT_OWNED on Windows Server

The same bug check can also occur on Windows Server.

Troubleshooting requires additional care because servers may contain:

• RAID controller drivers
• Backup agents
• Antivirus/EDR software
• Storage filter drivers
• Hypervisor components
• Network filter drivers
• Database applications
• Remote Desktop workloads

Before changing drivers on a production server:

1. Create or verify backups.
2. Confirm remote and console recovery access.
3. Record existing driver versions.
4. Check vendor compatibility.
5. Schedule downtime where necessary.

Repeated server BSODs should be investigated using crash dumps rather than repeatedly rebooting and waiting for the problem to recur.

How to Determine Whether the Problem Is a Driver

Driver involvement becomes more likely when:

• The same .sys module repeatedly appears in dumps.
• Crashes began after a driver update.
• Crashes occur when using a particular device.
• Removing certain software stops the crashes.
• Driver Verifier identifies the same driver.
• Multiple dumps show a consistent stack pattern.

One dump may not always provide enough evidence.

Comparing several dumps is often much more useful.

How to Determine Whether Hardware May Be Responsible

Hardware should receive greater attention when:

• Different BSOD codes occur randomly.
• Memory tests report errors.
• WHEA hardware errors appear.
• The computer freezes outside Windows.
• Crashes occur during BIOS diagnostics.
• Storage SMART/diagnostic tests fail.
• The system is unstable under load.
• Problems continue after a clean Windows installation with verified drivers.

In those situations test:

• RAM
• SSD/HDD
• CPU stability
• Motherboard
• Power supply
• GPU

Recommended Troubleshooting Order

For most RESOURCE_NOT_OWNED cases, use this sequence:

1. Note when the problem started

2. Check recent software and driver changes

3. Install appropriate Windows updates

4. Update or roll back suspect drivers

5. Analyze the crash dump

6. Run SFC and DISM

7. Check storage

8. Test RAM

9. Check BIOS and firmware

10. Perform a clean boot

11. Remove suspected third-party kernel software

12. Use Driver Verifier only if necessary

13. Perform deeper hardware diagnostics if crashes continue

This approach is preferable to randomly replacing hardware or reinstalling Windows immediately.

Preventing RESOURCE_NOT_OWNED Errors

Although not every BSOD can be prevented, the risk can be reduced by following good system-maintenance practices.

Keep Windows Updated

Install security, reliability, and compatibility updates.

Use Manufacturer-Supplied Drivers

Avoid unknown driver-download websites.

Keep Firmware Current

Maintain BIOS, SSD, RAID, docking station, and other relevant firmware.

Avoid Unnecessary Kernel Utilities

Avoid installing multiple:

• Antivirus products
• Disk optimization utilities
• Registry cleaners
• Driver updater tools
• Hardware monitoring utilities

Low-level utilities increase the number of kernel components running on the system.

Maintain Reliable Backups

BSOD troubleshooting may require driver removal, system restore, firmware changes, or Windows repair.

Always maintain backups of critical business data.

Frequently Asked Questions (FAQ)

1. What does RESOURCE_NOT_OWNED mean?

RESOURCE_NOT_OWNED means Windows detected that a thread attempted to release a kernel resource it did not own.

The corresponding bug check is 0x000000E3.

2. Is RESOURCE_NOT_OWNED a BSOD?

Yes.

RESOURCE_NOT_OWNED is a Windows bug check that results in a Blue Screen of Death when the condition is detected.

3. What is the RESOURCE_NOT_OWNED stop code?

The stop code is:

0x000000E3

It may also appear in WinDbg as:

RESOURCE_NOT_OWNED (e3)

4. What usually causes RESOURCE_NOT_OWNED?

A kernel-mode driver problem is an important possibility.

Other causes may include:

• Driver conflicts
• Security software
• Storage software
• File-system filters
• Corrupted system components
• Firmware problems
• Memory instability

Crash-dump analysis is the best way to narrow the cause.

5. Can faulty RAM cause RESOURCE_NOT_OWNED?

Memory instability can contribute to unpredictable kernel failures, so RAM should be tested if driver troubleshooting does not reveal the cause or if multiple different BSOD codes are occurring.

6. Can antivirus software cause this BSOD?

Potentially.

Security applications often install kernel-mode drivers for file, network, or process monitoring.

If the crashes began after an antivirus or endpoint-security installation or update, investigate that software and its drivers.

7. Can Windows Update cause RESOURCE_NOT_OWNED?

A Windows update may expose compatibility problems with an existing driver, or a driver delivered through an update may introduce an issue.

If the problem began immediately after an update, compare the timing carefully.

8. Should I reinstall Windows?

Not initially.

First investigate:

• Drivers
• Crash dumps
• System corruption
• RAM
• Storage
• Firmware
• Recently installed software

Reinstalling Windows should generally be a later troubleshooting option.

9. Where are Windows BSOD dump files stored?

Minidumps are commonly stored in:

C:\Windows\Minidump

A full or kernel dump may be stored as:

C:\Windows\MEMORY.DMP

10. How can I analyze RESOURCE_NOT_OWNED?

Use WinDbg and run:

!analyze -v

Then examine the stack, module names, driver names, failure bucket, and bug-check parameters.

11. Does ntoskrnl.exe cause RESOURCE_NOT_OWNED?

Not necessarily.

ntoskrnl.exe is the Windows kernel and commonly appears in crash stacks. Its presence alone does not prove that Windows itself caused the original problem.

The complete dump needs to be analyzed.

12. Can graphics drivers cause RESOURCE_NOT_OWNED?

A defective kernel-mode graphics driver could potentially contribute to a crash, although RESOURCE_NOT_OWNED is not exclusively a graphics-related bug check.

If the problem occurs during gaming, video rendering, GPU acceleration, or after a graphics-driver update, investigate the GPU driver.

13. Can storage drivers cause RESOURCE_NOT_OWNED?

Yes, storage and file-system components should be considered, particularly when crashes occur during disk-intensive activity.

Investigate:

• NVMe drivers
• RAID drivers
• Storage-controller drivers
• Backup software
• Encryption software
• File-system filter drivers

14. Is Driver Verifier safe?

Driver Verifier is a legitimate Windows diagnostic tool, but it deliberately stresses drivers.

It can cause additional crashes when defective drivers are present.

Use it carefully, especially on production systems.

15. How do I turn off Driver Verifier?

Open Command Prompt as Administrator and run:

verifier /reset

Then restart Windows.

16. Can SFC fix RESOURCE_NOT_OWNED?

SFC may fix the problem if corrupted Windows system files are contributing to the crash.

Run:

sfc /scannow

However, it cannot repair a defective third-party driver merely by scanning Windows files.

17. Can DISM fix RESOURCE_NOT_OWNED?

DISM can repair corruption in the Windows component store.

Run:

DISM /Online /Cleanup-Image /RestoreHealth

Then run:

sfc /scannow

DISM is useful for Windows corruption but does not replace driver-level diagnosis.

18. Why does RESOURCE_NOT_OWNED keep returning?

Repeated crashes usually mean the underlying cause has not been removed.

Possible reasons include:

• Faulty driver remains installed
• Software automatically reinstalls a driver
• Firmware remains incompatible
• Hardware instability continues
• Windows components are damaged

Analyze multiple dump files to identify patterns.

19. Should I replace my SSD because of RESOURCE_NOT_OWNED?

Not based on the stop code alone.

Test the SSD and investigate storage drivers first.

Replace hardware only when diagnostics provide reasonable evidence of failure.

20. Should I replace RAM because of RESOURCE_NOT_OWNED?

Not automatically.

Run memory diagnostics first. If RAM tests repeatedly report errors or multiple unrelated BSOD codes occur, deeper memory testing is justified.

Conclusion

RESOURCE_NOT_OWNED (0x000000E3) is a Windows kernel bug check indicating that a thread attempted to release a resource it did not own.

Because this involves kernel resource management, device drivers and other kernel-mode software are important areas to investigate.

The most effective troubleshooting strategy is not to randomly reinstall Windows or replace hardware. Instead:

• Review recent system changes
• Update or roll back suspect drivers
• Analyze Windows crash dumps
• Repair Windows using DISM and SFC
• Check storage and RAM
• Update firmware where appropriate
• Investigate security, backup, storage, and other low-level software
• Use Driver Verifier carefully when deeper driver diagnosis is necessary

For recurring RESOURCE_NOT_OWNED crashes, WinDbg crash-dump analysis is particularly valuable, because it can help identify the driver or kernel component involved at the time Windows detected the invalid resource operation.

#tags

#RESOURCE_NOT_OWNED #RESOURCE_NOT_OWNED_BSOD #RESOURCE_NOT_OWNED_Fix #RESOURCE_NOT_OWNED_Error #BugCheck0xE3 #0x000000E3 #WindowsBSOD #BSOD #BlueScreen #BlueScreenOfDeath #Windows11 #Windows10 #WindowsServer #WindowsTroubleshooting #WindowsRepair #BSODFix #BSODTroubleshooting #WindowsError #WindowsCrash #SystemCrash #DriverError #DriverTroubleshooting #FaultyDriver #WindowsDrivers #KernelDriver #KernelError #KernelCrash #WinDbg #WinDbgAnalysis #CrashDump #MemoryDump #Minidump #DumpAnalysis #WindowsDebugger #DriverVerifier #DeviceManager #WindowsUpdate #DISM #SFC #SystemFileChecker #CHKDSK #WindowsMemoryDiagnostic #RAMTest #BIOSUpdate #FirmwareUpdate #SafeMode #CleanBoot #EventViewer #ReliabilityMonitor #WindowsSupport