Recurring Access Violations on Database Services - (July 28, 2026)

Duration: Approx. 10 minutes

Affected Services: AIM/HFA/P+

Status: Resolved (vendor-confirmed workaround deployed; Microsoft has not yet released a permanent fix).

Executive Summary

Beginning July 28, 2026, database services began experiencing recurring access violation (AV) crashes, each forcing an unplanned restart of the SQL Server service. Investigation of the first dump identified a fatal access violation reading a near-null memory address, with the faulting call stack rooted in SQL Server's internal memory manager during routine statement-execution cleanup. Because the fault occurred entirely within Microsoft's own engine code, initial troubleshooting focused on several plausible contributing factors specific to this environment: a recently applied SQL Server security update affecting SQL Agent input handling, elevated system memory utilization at the time of the crashes, and the specific monitoring query active when the first dump was captured. A Microsoft Support case was opened and provided with the symbolicated stack trace and dump files for engine-level analysis. Microsoft Support identified the event as matching a known, publicly documented defect affecting SQL Server 2022 running on Windows Server 2025 when the Lock Pages in Memory (LPIM) policy is enabled for the SQL Server service account. Per Microsoft's guidance, the LPIM user right was removed from the SQL Server service account and subsequently applied proactively across all database servers in the environment. No further access violation dumps have been generated since the workaround was deployed.

Incident Timeline

Impact

Each access violation event forced an unplanned restart of the affected database service, briefly interrupting connectivity for all dependent applications and client environments during the restart and recovery window. The recurring nature of the issue — several hundred crash events over a short period — also generated a substantial volume of large memory dump files, consuming disk space and requiring repeated manual triage to distinguish this recurring, engine-level defect from unrelated causes. Because the fault originated inside SQL Server's own engine code rather than in a customer-specific query, stored procedure, or configuration, standard query- and workload-level troubleshooting could not resolve the underlying condition on its own.

Root Cause

Microsoft has published a known issue affecting SQL Server 2022 running on Windows Server 2025: under certain configurations, SQL Server can trigger access violation dumps when the Lock Pages in Memory (LPIM) Windows policy is enabled for the SQL Server service account. Microsoft's guidance notes that the presence of “Using locked pages in the memory manager.” in the SQL Server error log at startup is an indicator that a given instance may be affected. This is a defect in SQL Server's interaction with the Windows Server 2025 memory manager under LPIM, not a customer configuration error; LPIM itself is a widely used and previously supported setting for preventing the OS from paging out SQL Server's buffer pool. At the time of writing, Microsoft has not released a permanent fix and states that a resolution is being investigated for a future release of Windows Server 2025.

This finding is consistent with the crash evidence gathered during this incident: the faulting stack in every analyzed dump terminated inside SQL Server's internal memory-page management code, which is directly implicated in how SQL Server manages memory pages when LPIM is active. Other contributing factors considered earlier in the investigation — a recent SQL Agent security update and elevated system memory utilization — were not confirmed as the root cause and are believed to be coincidental or, at most, minor contributing conditions rather than the underlying defect. Reference: Microsoft SQL Server 2022 Release Notes, “Access violations in Windows Server 2025 with LPIM enabled.”

Resolution

Per Microsoft's documented workaround, the Lock Pages in Memory user right was removed from the SQL Server service account on the affected database server. To prevent recurrence on other instances running the same Windows Server / SQL Server 2022 combination, the same change was subsequently applied proactively across all database servers in the environment. Monitoring since deployment has shown no further access violation dumps. Because Microsoft has not yet released a permanent code fix, these environments will continue running without LPIM enabled until Microsoft ships a corrected release, at which point LPIM can be evaluated for re-enablement if still desired.

Note: separate, previously planned infrastructure changes on the affected database server (an increase in server memory and vCPU allocation, and a tempdb file resize) were carried out as general capacity and resilience improvements identified during this investigation. Those changes were not the corrective action for this defect and did not, on their own, resolve the access violations; the LPIM workaround above is the confirmed fix.