Windows Stop Code CREATE_DELETE_LOCK_NOT_LOCKED (0x00000014): Meaning and Troubleshooting
Quick Answer CREATE_DELETE_LOCK_NOT_LOCKED is a Windows bug check with the value 0x00000014. Microsoft says it occurs very infrequently. Its dedicated docume...
Quick Answer
CREATE_DELETE_LOCK_NOT_LOCKED is a Windows bug check with the value 0x00000014. Microsoft says it occurs very infrequently. Its dedicated documentation does not define the four bug-check parameters, identify a specific cause, or prescribe a code-specific fix. learn.microsoft.com
If a computer actually crashes with this code, preserve its crash dump and analyse it in WinDbg with !analyze -v. The stack, reported arguments, Windows build, and recent system changes are needed to determine what happened. The symbolic name alone cannot identify a faulty driver or hardware component. learn.microsoft.com
What Does the Name Mean?
The words CREATE_DELETE_LOCK_NOT_LOCKED suggest a lock-state problem in a create or delete operation. That is an interpretation of the name, not a detailed failure description supplied by Microsoft. Its official 0x14 page states only the bug-check value and that the bug check appears very infrequently. It does not specify which lock, object, operation, or thread is involved. learn.microsoft.com
For that reason, avoid treating the name as proof that a particular application failed to lock a file or that a user must change file permissions. A Windows bug check records a kernel-level system halt; its actual execution context must come from the dump.
Stop Code at a Glance
| Field | Documented information |
|---|---|
| Bug-check value | 0x00000014 |
| Symbolic name | CREATE_DELETE_LOCK_NOT_LOCKED |
| Frequency | Microsoft says it appears very infrequently. |
| Parameter definitions | Not provided on the dedicated Microsoft page. |
| Specific cause or resolution | Not provided on the dedicated Microsoft page. |
What Can Cause an Actual 0x14 Crash?
There is no Microsoft-published list of causes specific to bug check 0x14 in its dedicated reference. A driver defect, an invalid execution path, or corruption may be possibilities in a kernel crash investigation, but none should be declared the cause of a particular CREATE_DELETE_LOCK_NOT_LOCKED crash without dump evidence.
A useful investigation asks:
- What code was executing when Windows stopped?
- Which thread and modules appear on the failing stack?
- Does a third-party driver appear in a relevant part of the call path?
- Did the issue begin after a driver, device, firmware, or Windows change?
- Can the crash be reproduced, and does the same stack recur?
These questions narrow the case without assigning an undocumented meaning to the stop-code name.
How to Investigate the Crash
1. Confirm the exact stop code
Check the original crash record or dump for 0x00000014. Similar-looking numbers represent different bug checks. If you copied the entry from a list of Windows stop codes rather than from an actual blue screen, there is no individual crash to diagnose.
2. Preserve the dump
Keep the crash dump generated by the affected system. A screenshot of the stop-code name confirms what appeared on screen, but a dump can contain the arguments, stack, loaded modules, and other context needed for analysis.
3. Open it in WinDbg
Run:
!analyze -vRecord the reported bug-check code and arguments, stack trace, and any module named by the analysis. Microsoft’s general bug-check reference recommends !analyze for displaying bug-check information. Its automated output is a starting point; inspect the stack before concluding that a named module caused the failure. learn.microsoft.com
4. Examine the call stack
Use a stack-display command such as:
kvLook at the functions leading to the bug check and the driver modules in that path. If the dump lacks enough information, a kernel or complete dump from a reproducible crash may be more useful than repeatedly interpreting a limited screenshot.
5. Correlate the crash with system history
Check the System log in Event Viewer and note changes made before the first crash. If the same crash follows a particular driver update or device installation, investigate that change alongside the dump. A timing match is a lead, not proof.
6. Escalate with the evidence
When asking a driver vendor or developer for help, provide the dump or relevant WinDbg output, Windows version, hardware details, and a description of how to reproduce the failure. That gives them a basis to investigate the actual code path.
If You Develop the Affected Driver
Start with the stack and source code it identifies. Trace the relevant create or delete path, its synchronization assumptions, and its error handling. Check whether the same operation can run concurrently, whether a lock is acquired before a path that assumes ownership, and whether cleanup code follows a different path from normal execution.
These are general code-review checks, not confirmed explanations of bug check 0x14. Microsoft does not publish enough detail on its 0x14 page to equate this stop code with a specific lock API or to interpret its parameters. learn.microsoft.com
What Should an End User Do?
If the blue screen happened once, record the code and preserve the dump in case it recurs. If it repeats:
- Compare the time of each crash with driver and device changes.
- Obtain and review the dump analysis.
- If a particular third-party driver is supported by the evidence, check its vendor for an appropriate update or rollback.
- Provide the dump to the vendor or an experienced Windows debugger when the cause remains unclear.
Avoid applying a generic registry edit, disabling unrelated services, or replacing hardware solely because an article lists them as possible blue-screen remedies. Microsoft’s 0x14 reference provides no basis for a universal fix. learn.microsoft.com
Frequently Asked Questions
What is CREATE_DELETE_LOCK_NOT_LOCKED?
It is the symbolic name for Windows bug check 0x00000014. Microsoft says this bug check appears very infrequently. learn.microsoft.com
Does it mean a file is locked or cannot be deleted?
The official 0x14 page does not say that. Do not infer a file-permission problem from the name alone. learn.microsoft.com
Which driver causes this stop code?
Microsoft does not identify one. Examine the actual crash dump and stack to investigate the driver or code path involved.
What do its four parameters mean?
Microsoft’s dedicated 0x14 page does not define them. Record their values from WinDbg, but do not apply parameter definitions from another bug check. learn.microsoft.com
Is this the same as EMPTY_THREAD_REAPER_LIST (0x13)?
No. 0x13 and 0x14 are distinct entries. Microsoft says 0x13 is not currently used, while it describes 0x14 as occurring very infrequently. learn.microsoft.com
Can !analyze -v fix the crash?
No. It analyses a dump and presents diagnostic information. Any corrective action should follow from the evidence it reveals. learn.microsoft.com
Summary
CREATE_DELETE_LOCK_NOT_LOCKED (0x00000014) is a very rare Windows bug check with limited official documentation. Its name hints at a lock-state issue, but Microsoft does not define a precise cause, parameters, or universal remedy. For an actual occurrence, verify the code in the dump, run !analyze -v, inspect the stack, and investigate the driver or code path indicated by the evidence. learn.microsoft.com
Sources
Was this guide useful?
Your answer helps us keep BISONKB accurate and practical.