As reported by BleepingComputer, Microsoft has confirmed a known issue in Windows Server 2025 where recent memory-management changes are causing access violations, memory corruption, and unexpected termination in applications that rely on Address Windowing Extensions (AWE). The highest-impact casualty is SQL Server running with the Lock Pages in Memory (LPIM) policy enabled—a configuration that is extremely common in performance-sensitive enterprise deployments.
From a defender's perspective, this is not a security vulnerability in the traditional sense, but it is a serious availability and integrity risk that deserves incident-response-level attention. Memory corruption inside a database engine can silently compromise query results, corrupt indexes, or produce crash dumps at the worst possible moment—during maintenance windows or peak load. The 0xC0000005 access violation signature is well known, but in this context it points to a platform regression rather than attacker activity, which makes it easy to misdiagnose.
Why this matters more than a typical KB article
LPIM is not an edge-case tuning knob. It is the recommended configuration for large-memory SQL Server instances, particularly those hosting tier-1 ERP, financial, and healthcare databases. By disabling the OS ability to page SQL Server's buffer pool to disk, LPIM delivers predictable latency and avoids pathological paging under memory pressure. Microsoft's own guidance has long encouraged it for systems with more than 32GB of RAM. That means the population of exposed systems is likely substantial, and the workaround—disabling LPIM—directly erodes the performance characteristics that justified the deployment in the first place.
Issue profile
| Attribute | Detail |
|---|---|
| Affected platform | Windows Server 2025 (all current builds) |
| Affected workload | Applications using AWE; SQL Server with LPIM enabled is the primary reported case |
| Symptoms | 0xC0000005 access violations, memory corruption, DBCC CHECKDB failures, SQL Server crash dumps, unexpected service restarts, "Using locked pages in the memory manager" log entries at startup |
| Root cause | Memory-management behavior change in Windows Server 2025 versus earlier releases |
| Patch status | No permanent fix available; fix promised in a future Windows update |
| Workaround | Disable LPIM for the SQL Server service account, or disable AWE for other affected applications |
| Exploitation | Not a security exploit; availability/integrity regression |
The deeper concern is integrity, not just uptime. If memory corruption is silently affecting buffer pool contents before a crash is triggered, DBCC CHECKDB failures may only be the visible tip—undetected data divergence is the worst-case outcome.
Who is at risk
Shield53 Recommendations
- Triage immediately. Audit all Windows Server 2025 hosts for SQL Server instances with LPIM enabled. Check SQL Server error logs for "Using locked pages in the memory manager" entries and recent crash dump folders.
- Validate data integrity. Run DBCC CHECKDB against affected databases during the next maintenance window. Treat any CHECKDB failures as potential data-corruption incidents, not just routine errors.
- Apply the workaround selectively. Disabling LPIM restores stability but degrades performance under memory pressure. Test the trade-off in pre-production first; do not blanket-disable across fleet without measurement.
- Consider holding migration. For mission-critical SQL workloads still on Windows Server 2022, defer upgrade to 2025 until Microsoft ships the permanent fix and the community validates it.
- Configure alerting. Add monitoring rules for SQL Server service restart events, 0xC0000005 in application logs, and sudden increases in crash dump generation on 2025 hosts.
- Re-test all AWE-dependent apps. This is not a SQL-only problem—any third-party or legacy application using AWE should be revalidated against 2025 before promotion to production.
Windows Server 2025 is still early in its adoption curve, which is exactly when regressions like this surface. The lesson here is operational, not just technical: platform upgrades need the same validation rigor for memory and kernel behavior changes as they do for security features. Until Microsoft ships the fix, treat LPIM-on-2025 as a known risk and plan accordingly.
