What RESOURCE_NOT_OWNED means

Bug check 0xE3 means a thread tried to release a resource, a kind of internal lock, that it did not own. Microsoft’s reference does not list causes, but the meaning implies a driver or component whose lock handling is wrong, such as releasing a lock twice or on the wrong thread. It is an uncommon stop code, so a recent driver, update or low-level program is the most useful place to start.

Common causes

  • A driver or file-system filter that handles locks incorrectly
  • A recently installed or updated driver, especially for storage, security or backup software
  • An outdated component that conflicts with the installed Windows version

How to fix RESOURCE_NOT_OWNED

Work through these in order and test after each one. Stopping as soon as the crashes stop tells you which change mattered.

  1. Undo the most recent change. If the blue screens began after a Windows update, a new driver or new software, remove that change first. Uninstall the update from Settings, Windows Update, Update history, or roll a driver back in Device Manager (right-click the device, Properties, Driver, Roll Back Driver).
  2. Install pending Windows updates. Open Settings, Windows Update and install anything waiting, including optional driver updates from the PC maker. A fixed component may already be available.
  3. Note the file name on the blue screen. If the screen shows a line such as "What failed" followed by a .sys file, write it down. Searching that file name shows which driver it belongs to, which tells you what to update or remove. The named file is the code that crashed, which is not always the root cause.
  4. Check security, backup and disk tools. Antivirus, backup, encryption and disk utilities often install file-system filter drivers. Update or temporarily uninstall the one you added most recently, and retest.
  5. Repair Windows system files. Open Terminal (Admin) and run sfc /scannow. If it reports damage it could not repair, run DISM /Online /Cleanup-Image /RestoreHealth, restart, and run sfc /scannow once more.

Reading the crash evidence for 0xE3

Microsoft’s reference gives the first three parameters as the address of the resource, the address of the thread, and the address of the owner table, if one exists. They are mainly useful to a developer with a debugger, together with the call stack that shows which driver made the release.

For most people, the practical evidence is timing. Reliability Monitor shows when the crashes started, and a driver, update or tool installed at that time is the most likely cause.

Match what you observe to the next check
What you observeWhat it may suggestNext check
The crash began after a driver or software installThat component may mishandle locksRemove or update it and retest
The crash happens during disk-heavy work such as backupA file-system filter driver may be involvedUpdate or disable backup or security tools one at a time
The crash began after a Windows updateAn older driver may conflict with the new buildInstall the maker’s current drivers

Source: Microsoft Learn: Bug Check 0xE3 RESOURCE_NOT_OWNED ↗

When to stop and protect your data

If the crash repeats with the same driver or program involved, keep the minidump and report it to the maker. A debugger can show the resource and the thread that tried to release it.

Not sure this is your code?

The stop code appears as text on the blue screen. If the PC restarted before you could read it, open Event Viewer, then Windows Logs, then System, and look for a BugCheck event with ID 1001. You can also search all stop codes.

Related guides

Other system file and kernel errors