| Previous | Next |
| ERROR_FATAL_APP_EXIT | ERROR_WAS_UNLOCKED |
ERROR_PREDEFINED_HANDLE
A registry operation encountered a predefined key handle
ERROR_PREDEFINED_HANDLE corresponds to Win32 error value documented as: The specified registry key is referenced by a predefined handle. Windows uses special handles for roots such as HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. This result warns that code is treating one of those predefined handles as though it were an ordinary handle returned by RegOpenKeyEx.
Where the result appears in real systems
- Registry wrappers that close every received HKEY unconditionally.
- Ownership-transfer code that cannot distinguish borrowed root handles from opened subkeys.
- Cleanup logic shared between predefined roots and dynamically opened keys.
Evidence to collect before changing the system
record the numeric HKEY value and the API being called; trace where ownership of the handle was assigned; verify whether the failing path begins with HKLM, HKCU, HKCR, HKU, or HKCC; enable Application Verifier handle checks for a reproducible case
Keep the original numeric value, symbolic name, API return path, thread and process identity, and the exact timestamp in one diagnostic record. Those fields prevent later layers from replacing this specific result with a generic failure and make correlation with ETW or Event Viewer practical.
Handling and recovery
Represent predefined roots as non-owning handles. Only close handles actually returned by an open or create operation, and make wrapper ownership explicit in its type or constructor.
Code that receives this result should classify it according to the operation that produced it: completion information, a recoverable environmental condition, or a programming defect. The result classification should be made at the API boundary where the caller still knows the handle, object, flags, and expected state.
What not to infer from this code
This result is not a permissions error and changing ACLs will not fix it. It identifies incorrect handle lifetime or API usage around a registry root.
Implementation guidance
Preserve this result through logging and telemetry instead of immediately converting it to free-form text. When it crosses an HRESULT boundary, record both the original Win32 value and the converted HRESULT; when it crosses RPC, JSON, or another protocol, include an explicit error-domain field so the receiver does not convert it twice.
A useful automated test for this Win32 error should reproduce the relevant state transition, assert the exact returned value, and verify cleanup after both the normal and exceptional path. The test for this Win32 error should also check that a retry is performed only when the underlying state can genuinely change, because unconditional retries often hide ownership, architecture, power, or resource-negotiation defects.
References
Looking for a different code? Search another status or error code.