Error Code Search

Access is denied.

Likely cause: Permissions or UAC. Verify effective NTFS / share permissions, check that the running account has the right role, look for a consent prompt that was dismissed. In Windows Update (CBS) this means the servicing stack lacks rights to a file or registry key, check %Windir%\logs\CBS\CBS.log for the object just before the error.

The system cannot find the file specified.

Likely cause: Path typo or recent uninstall. Check the path resolves, including drive letters and UNC. Often shows up after policy removed a file, or as a Windows Update corruption symptom.

The system cannot find the path specified.

Likely cause: Same as 0x80070002 but missing a directory rather than the file.

Access is denied. (bare Win32 error 5)

Likely cause: Same root cause as the HRESULT 0x80070005, surfaces as decimal 5 / 0x5 from GetLastError. Check NTFS/share ACLs, token privileges, and whether the operation needs elevation.

Not enough memory resources are available to process this command.

Likely cause: Genuine memory pressure or desktop heap / handle exhaustion. Check committed memory and per-process handle counts; for RDP/Terminal Services watch SessionViewSize and desktop heap limits.

The process cannot access the file because it is being used by another process.

Likely cause: Something has the file locked. In Windows Update this is almost always a non-Microsoft filter driver (antivirus), do a clean boot and retry, or use Process Monitor to find the process touching the file named in CBS.log.

One or more arguments are invalid (the parameter is incorrect).

Likely cause: Generic invalid-argument error. Look at the operation just before this, often a config value is malformed (e.g. GUID with surrounding whitespace).

Failed to allocate necessary memory (ran out of storage).

Likely cause: COM/HRESULT form of ERROR_OUTOFMEMORY (14). The component couldn't allocate, check overall memory pressure and the process's own working set / leak history.

Not implemented.

Likely cause: A COM method that exists in the interface isn't implemented by this object/version. Usually a version mismatch or calling an optional method the provider doesn't support.

No such interface supported.

Likely cause: QueryInterface failed, the COM object doesn't implement the requested interface. Often a broken/partial registration or a mismatched component version.

Invalid pointer (NULL was passed where a pointer was required).

Likely cause: Almost always a caller/code defect, a required out-pointer or buffer was NULL. Look one frame up the stack.

Operation aborted.

Likely cause: The operation was cancelled, often deliberately (user cancel, a dependent call returned a failure). Check the surrounding log for what triggered the abort.

The handle is invalid.

Likely cause: A handle was already closed, never opened, or belongs to a different object/process. Common after a race or a double-close.

This operation returned because the timeout period expired.

Likely cause: Network latency or a hung server. Check connectivity to the endpoint and retry; could also be a slow disk on the target.

The server name or address could not be resolved.

Likely cause: DNS failure (WinINet). Verify resolver, check VPN/split-tunnel routing, and try `Resolve-DnsName` against the same record.

The operation timed out (WinINet).

Likely cause: Windows Update / WinINet couldn't reach the update source. Confirm the device can reach the Windows Update endpoints (or WSUS/Configuration Manager/Intune) and that a proxy or firewall isn't dropping the connection.

A security/TLS error occurred (commonly the system clock is out of sync).

Likely cause: Classic Windows Update / activation symptom, fix system time, then retry. Also appears when the TLS trust chain can't be built (missing root, MITM proxy).

Outlook cannot connect to the outgoing SMTP server.

Likely cause: Network/host/port issue with SMTP. Check the server name, port (587/465), and whether antivirus is intercepting SMTP.

Outlook: the SMTP server rejected the sender address.

Likely cause: Authentication or relay restriction. Verify SMTP auth is configured and the sender matches the authenticated mailbox.

Unspecified failure.

Likely cause: Generic catch-all, almost always look at the surrounding log entries; the real error is usually one line above.

Catastrophic failure.

Likely cause: Rarely descriptive on its own. In WMI/COM this usually means provider corruption, try `winmgmt /verifyrepository`.

Fatal error during installation (Windows Installer).

Likely cause: Check the matching MSI log under %WINDIR%\Logs or %TEMP%. Often a prerequisite (.NET, VC++ runtime) is missing. Also a very common Windows Update / .NET cumulative-update failure, run the matching component repair.

Another installation is already in progress.

Likely cause: Kill any running msiexec.exe or wait it out. Common during Intune Win32 app rollouts.

Cannot find object or property (cryptography).

Likely cause: A certificate or key was expected and isn't in the store. Re-issue or re-import the cert; check current user vs local machine store.

The DNS operation timed out.

Likely cause: Authoritative server isn't answering for that record. Try a different resolver to confirm; if it's external, the customer's DNS host has a problem.

The RPC server is unavailable.

Likely cause: The RPC client couldn't reach the server endpoint, TCP connect failed. Causes: DNS resolution, the target service not running, or a firewall blocking port 135 / the dynamic RPC range (49152-65535). Classic in AD replication, certificate enrollment, WMI, and roaming-profile loads. Test with `portqry -n <host> -e 135`.

HTTP 400, bad request from a Microsoft endpoint (BITS/HTTP).

Likely cause: Frequently the Intune / WSUS agent, the payload to the management endpoint is malformed; rebuild the device's enrolment certs or run `dsregcmd /leave` + re-join.

Windows Update: the proxy or target server name cannot be resolved.

Likely cause: Same as ERROR_WINHTTP_NAME_NOT_RESOLVED. For a direct-to-WU client it's an internet/DNS problem; for a WSUS client the device can't reach the WSUS server (check the WUServer registry value and DNS).

Windows Update: HTTP 407, proxy authentication required.

Likely cause: The WinHTTP/WinINet proxy is requiring auth that the WU agent can't satisfy. Set the system (WinHTTP) proxy with `netsh winhttp set proxy`, or allow the update source through the proxy without user auth.

Windows Update: HTTP 503, the service is temporarily unavailable/overloaded.

Likely cause: Usually a WSUS/IIS problem: the WSUS app pool has hit its memory limit or too many clients. Raise the WSUS app pool private memory limit (4-8 GB) and recycle it; otherwise a transient WU-side overload, retry later.

Windows Update: the operation failed for all of the updates.

Likely cause: Multiple root causes; most often antivirus blocking access to folders like SoftwareDistribution. Exclude/disable AV and retry; analyse %Windir%\logs\CBS\CBS.log for the specific file or folder being blocked.

Windows Update: the operation didn't complete because no interactive user is logged on.

Likely cause: The update is configured to require an interactive user and none is signed in. Expected for some deferred/install-on-logon updates, have a user sign in, or adjust the deadline/active-hours policy.

Windows Update: external .cab processing completed with some errors.

Likely cause: Commonly caused by web-filtering appliances mangling the .cab download. Add the device's update endpoints to the filter's exception list.

The source files could not be found (component store).

Likely cause: Component store corruption or a missing payload, common installing .NET 3.5 / Features on Demand and during update repair. Run `DISM /Online /Cleanup-Image /RestoreHealth` (point /Source at known-good media if the device can't reach Windows Update) then `sfc /scannow`.

The source files could not be downloaded.

Likely cause: DISM/FoD couldn't fetch the payload (no internet, blocked, or GPO 'Specify settings for optional component installation' points nowhere). Supply an explicit /Source path to install media.

DISM failed because Group Policy disallowed connecting to Windows Update for source files.

Likely cause: The 'Specify settings for optional component installation and component repair' policy blocks WU as a repair source. Either set 'Download repair content … directly from Windows Update' or pass a /Source path to media.

The component store (WinSxS) is in an inconsistent state.

Likely cause: A servicing component is missing/corrupt. Run `DISM /Online /Cleanup-Image /RestoreHealth` then `sfc /scannow`; if RestoreHealth itself fails, supply a /Source from matching media.

The referenced assembly could not be found (component store).

Likely cause: Same family as the other CBS corruption errors, a component is partially installed. Repair with DISM /RestoreHealth + sfc /scannow.

The file or directory is corrupted and unreadable.

Likely cause: During servicing this points to component-store corruption; otherwise suspect the disk. Run DISM /RestoreHealth + sfc /scannow, and check the drive with chkdsk if it recurs.

This drive is locked by BitLocker Drive Encryption.

Likely cause: Unlock before you can use it: `manage-bde -unlock <drive>: -RecoveryPassword <48-digit key>` (or -Password). The recovery key lives in Entra/AD, the Microsoft account, or your MDM/MBAM store.

BitLocker protection is suspended on this drive (clear key in use).

Likely cause: Protection is suspended, so the volume auto-unlocks with an unencrypted key. Re-enable with `manage-bde -protectors -enable <drive>:`, common after a firmware/feature update left BitLocker suspended.

BitLocker metadata couldn't be updated, it was locked by another process.

Likely cause: A concurrent BitLocker operation held the metadata. Wait for any in-flight manage-bde / encryption task to finish and retry.

Access denied (kernel-level).

Likely cause: Lower-level cousin of 0x80070005. Often surfaces in Event Viewer for service starts and printer drivers; the caller lacks the required access right.

A memory access violation occurred.

Likely cause: Almost always a code defect, a process read/wrote memory it shouldn't. The classic app-crash and BSOD 0x7E exception code. Capture a dump (WER / procdump) and read the faulting module; if it's a Microsoft DLL (ntdll, kernelbase) the real culprit is usually a third-party module.

A heap corruption was detected.

Likely cause: A process corrupted its own heap (buffer overrun, double-free, use-after-free). Common app-crash exception. Update the app/runtime first; if it persists, capture a dump and enable page heap (gflags) to catch the offender.

The attempted logon is invalid (bad username or authentication info).

Likely cause: Wrong username or password; pair with the Logon Type to narrow down (10 = RDP, 3 = network share). Shows up as the SubStatus on Event ID 4625.

The value provided as the current password is incorrect.

Likely cause: Bad password on a password-change call (not a plain logon). On a DC this also appears in 4776 audits, often a hint that AD replication hasn't caught up, or a cached/old credential somewhere.

The new password is malformed (contains disallowed characters).

Likely cause: On a password change, the proposed password has characters that aren't allowed. Re-enter without unusual/unicode characters.

A policy restriction prevents the password from being changed.

Likely cause: The new password fails length/complexity/history, or it's being changed too soon (minimum password age). Check the domain (or fine-grained) password policy and the history requirement.

The specified account does not exist.

Likely cause: Trust / replication issue or a stale cached credential. Confirm the user exists in the correct directory; on a 4625/4776 this means the username didn't resolve at all.

The user account password has expired.

Likely cause: Force a password reset; if the user can't change it at sign-in, look at policy and check fine-grained password policies.

The password must be changed at the next logon.

Likely cause: The account is flagged 'User must change password at next logon'. Over RDP with NLA this can block sign-in entirely (the user can't reach the change-password screen), clear the flag or set a password, or disable NLA temporarily.

The referenced account is currently disabled.

Likely cause: Re-enable the account in AD/Entra (or upstream and re-sync). Distinct from lockout, this is an admin-set disabled flag.

The user account has expired.

Likely cause: The account's 'Account expires' date has passed. Clear or extend the expiry date on the account (Account tab in ADUC).

The user account has been automatically locked.

Likely cause: Find the source of the lockout, Event ID 4740 on the PDC emulator. Common culprits: cached creds on a phone, mapped drives, scheduled tasks, service accounts.

The user account has time restrictions and may not be logged onto at this time.

Likely cause: Check 'Logon Hours' on the account. Rare unless the customer uses logon-hour restrictions.

There are currently no logon servers available to service the logon request.

Likely cause: The client can't reach a domain controller (DNS pointing at the wrong resolver, VPN down, DC offline, or a purged cached credential). Check the device's DNS is the DC/internal resolver and that a DC is reachable; LsaSrv 45058 nearby means the cached credential was evicted.

The trust relationship between this workstation and the primary domain failed.

Likely cause: The machine account password is out of sync with AD (or the computer account was deleted/reset). Sign in locally and run `Test-ComputerSecureChannel -Repair -Credential (Get-Credential)` or `netdom resetpwd`; rejoin only as a last resort.

Trying to use a deleted user.

Likely cause: The account was removed mid-session. Often a sync deletion from Entra Connect, restore from the Entra recycle bin if needed.

The account is locked because the user tried to sign in too many times with an incorrect ID or password (or the sign-in came from a malicious IP).

Likely cause: Smart Lockout, or a sign-in blocked from a flagged IP. Check the sign-in log Failure reason to tell which. Investigate the source IP for password-spray; unlock via Entra once cleared.

The password is expired.

Likely cause: User must change password, offer the reset, or have an admin reset it. Check the change-password URL is reachable from the device.

The user account is disabled.

Likely cause: Re-enable in Entra (or upstream AD if synced, then force a sync).

Session information is not sufficient for single sign-on.

Likely cause: Not really an error, the user simply isn't signed in yet (commonly seen with prompt=none). Expected when unauthenticated; if it recurs for an already-signed-in user the SSO session was lost or invalid.

No tenant-identifying information was found in the request or implied by the credentials.

Likely cause: App's authority is /common but the user has no tenant context. Point the app at a specific tenant or sign in with a full UPN, not an alias.

Strong authentication is required and the user did not pass the MFA challenge.

Likely cause: MFA was required and not satisfied. Confirm the user has a registered MFA method and completed the prompt.

Due to a configuration change (e.g. a Conditional Access policy) MFA is required to access the resource.

Likely cause: Triggered by Conditional Access, per-user MFA, or a new sign-in location. Identify the CA policy in the sign-in logs; the client should retry with an interactive MFA prompt.

MFA is required but the user has not registered a method (non-interactive).

Likely cause: A managed user needs to register security info; a federated user needs the MFA claim from their IdP. Have them complete registration at aka.ms/mfasetup.

The user needs to enroll for second-factor authentication (interactive).

Likely cause: Interactive form of the MFA-registration interrupt. The user is being walked through security-info registration, let them complete it at aka.ms/mfasetup.

The signed-in user is not assigned to a role for the application.

Likely cause: User assignment is required and the user isn't assigned. Add the user (or a group they're directly in, nested groups aren't honoured) to the Enterprise App.

Invalid username or password.

Likely cause: Genuinely wrong credentials, or the account is federated and the upstream IdP rejected. Check sign-in logs for federation hints.

Tenant-identifying information was not found in the request.

Likely cause: Usually the domain isn't onboarded to Entra. Confirm the customer's domain via the Tenant Lookup tool.

External security challenge was not satisfied.

Likely cause: A Conditional Access control (session control, compliant device, terms of use, etc.) wasn't met. Check which CA policy applied in the sign-in logs.

The provided grant has expired due to it being revoked; a fresh auth token is needed.

Likely cause: The refresh token was invalidated, almost always because the user changed/reset their password, or an admin revoked sessions. Sign out and back in to the app (Outlook/Teams/OneDrive) to get a fresh token. Compare the token's issued time to the user's TokensValidFrom date.

The server terminated an operation because it encountered a client request loop.

Likely cause: Usually a redirect loop in the app. Clear cookies and check the app's reply URL.

Your device is required to be compliant to access this resource.

Likely cause: Conditional Access requires a compliant device and this one isn't. Enrol/remediate the device in Intune, or grant an exception in the policy.

Access has been blocked by Conditional Access policies.

Likely cause: Check the sign-in log entry, the policy name is listed. Common causes: location, device platform, app-enforced restrictions.

User blocked due to risk on the home tenant.

Likely cause: Identity Protection flagged the user. Confirm the activity, then dismiss the risk or force a secure password reset.

The user or administrator has not consented to use the application.

Likely cause: Send an interactive consent request, or (for admin-only scopes) grant admin consent via Enterprise App → Permissions → Grant admin consent.

The user declined to consent to access the app.

Likely cause: Expected when the user clicks 'Cancel' on the consent screen (and a normal step at the end of the admin-consent workflow). Have them retry and accept.

The refresh token has expired or is invalid.

Likely cause: User needs to sign in interactively. Often happens after a long idle period, a password reset, or session revocation.

The authentication method used does not match the requested method.

Likely cause: The SAML request's RequestedAuthnContext/AuthnContextClassRef differs from how the user already authenticated (e.g. WIA vs MFA). Ask the app to drop RequestedAuthnContext, or force a fresh auth (ForceAuthn="true").

The external account the user signed in with doesn't exist in the resource tenant, so the tenant's MFA requirement can't be satisfied.

Likely cause: Cross-tenant/guest MFA can't be met. Add the user as a guest (B2B) and adjust Cross-Tenant Access Settings. Can also appear for synced users when the ImmutableID (sourceAnchor) is mismatched between AD and Entra.

The grant requires admin permission.

Likely cause: Admin consent is required for the requested scopes (or the app is flagged risky). Grant tenant-wide from Enterprise App → Permissions, after reviewing the app.

Account selection is required, or no usable cached session exists for silent sign-in.

Likely cause: Seen on silent (prompt=none) flows when more than one account is cached or none matches. Retry interactively so the user can pick the right account. Also appears when signing in to the Entra admin center with a personal Microsoft account that has no directory.

The user account from the identity provider does not exist in the tenant and cannot access the application.

Likely cause: A guest/cross-tenant user who isn't in this tenant, or the wrong sign-in authority (single-tenant /tenantId used for a multitenant/personal-account app). Invite the user as a B2B guest, or fix the app's authority (/organizations, /common, or /consumers).

The user account does not exist in the directory.

Likely cause: Mistyped UPN, or the app targeted the wrong tenant. Confirm the account exists in this tenant; add as a guest if it's an external user who should have access.

Application with the given identifier was not found in the directory.

Likely cause: The app/client ID doesn't match a registration in the tenant being signed into. Confirm the app is multi-tenant if cross-tenant, that it's been consented in the tenant, and that the right tenant is targeted.

Invalid client secret is provided.

Likely cause: The app's client secret is wrong, expired, or was rotated. Generate a new secret in the app registration → Certificates & secrets and update the caller. (Watch for a trailing space when pasting; the secret value, not the secret ID, is what's needed.)

Intune sync was not successful (generic).

Likely cause: Most common Intune error. Check the device's MDM diagnostics report; usually a single policy failed and is shown there.

Intune MAM authentication required.

Likely cause: User needs to re-authenticate the Company Portal or the protected app.

Policy was not applied because it was rejected by the device.

Likely cause: Check the policy's settings catalog, a conflict with an MDM CSP usually causes this.

App removal failed.

Likely cause: Intune Win32 / store app removal, check IntuneManagementExtension.log and the AppX provisioning state.

App install failed because another install was running.

Likely cause: Retry after current install completes. Often caused by ESP racing a user-initiated install.

Network location not reachable (the device is offline).

Likely cause: Device couldn't reach the Intune endpoints when the policy applied. Check connectivity, retry sync.

Enrollment failed, there was a problem authenticating the account or device.

Likely cause: The Entra/device token wasn't accepted at the enrollment endpoint. Confirm the user has a valid Intune licence and MFA satisfied, the device clock is correct, and retry.

Enrollment failed, this user isn't authorized to enroll.

Likely cause: The user isn't in MDM scope or lacks enrollment rights. Set Mobility (MDM) user scope to All (or include the user's group), and confirm a valid Intune licence.

Enrollment failed, there was an error communicating with the server.

Likely cause: A ConfigMgr/management-server communication failure during enrollment (co-management/CMG path). Check connectivity to the enrollment and ConfigMgr endpoints and retry; review the enrollment diagnostics if it persists.

Enrollment failed, an enrollment is already in progress.

Likely cause: Wait for the in-progress enrollment to finish, or remove the partial enrollment under Access work or school and retry.

The device is already enrolled in MDM.

Likely cause: Another MDM (or a previous Intune enrollment) still owns the device. Unenroll the old MDM (Access work or school / clear stale HKLM\Software\Microsoft\Enrollments keys), then re-enroll.

Enrollment failed, the device cap for the account has been reached.

Likely cause: The user hit the enrollment device limit. Raise it (Enrollment device limit restrictions) or remove stale devices from the user, and check 'Maximum number of devices per user' in Entra Device settings.

Enrollment failed, Windows MDM enrollment isn't allowed for this device.

Likely cause: Windows (MDM) enrollment is disabled in the tenant. Devices → Enroll devices → Enrollment device platform restrictions → allow Windows (MDM). The single most common Autopilot/enrollment failure ('Your organization does not support this version of Windows').

Enrollment failed, there was an error with the user's licence.

Likely cause: The enrolling user is missing a valid Intune (or M365 with Intune) licence. Assign one in the M365 admin center and retry.

Enrollment failed, the UPN domain is unroutable, or MDM user scope is None.

Likely cause: The user's UPN suffix isn't a verified/routable domain (e.g. a .local), or MDM user scope is set to None. Fix the UPN suffix (or configure Alternate Login ID) and set Mobility (MDM) user scope to All or a group.

Enrollment conflict, MDM auto-enrollment clashing with the legacy Intune PC agent.

Likely cause: Auto-enrollment is on and the old Intune PC software client is still installed. Uninstall the legacy Intune client (or pause MDM auto-enrollment) before MDM enrollment can complete.

Autopilot device enrollment failed, the device is running Windows Home edition.

Likely cause: Autopilot/Entra join needs Pro, Enterprise, or Education. Upgrade the edition (e.g. via a licence/subscription activation) and re-run enrollment.

Device registration failed, this user isn't authorized to join devices.

Likely cause: Entra device-join is restricted. In Entra → Devices → Device settings, set 'Users may join devices to Microsoft Entra ID' to All (or add the user/group), and confirm the per-user device quota isn't exceeded.

Autopilot CSV import failed, the device is already registered (806 in this tenant, 808 in another tenant).

Likely cause: The hardware hash already exists as an Autopilot device. Delete the existing Autopilot device record (806), or have the owning tenant deregister it / open a Microsoft support case to release it (808), then re-import.

MDM sync failed, missing or inaccessible client-certificate private key.

Likely cause: Assert the DMClient AllowRecovery CSP (./Device/Vendor/MSFT/DMClient/Provider/MS DM Server/Recovery/AllowRecovery = 1) so the device self-heals, then sync. Default-on for newer Windows builds.