Microsoft has confirmed that a memory-management change in Windows Server 2025 can crash SQL Server with access-violation dumps, and it says on its own documentation that it doesn't have a fix yet. The trigger isn't exotic. It's a setting Microsoft has recommended for large-memory database servers for years: Lock Pages in Memory.

What exactly breaks?

SQL Server instances that run with the Lock Pages in Memory (LPIM) Windows policy turned on can crash with an access violation, error code 0xC0000005, after moving to Windows Server 2025. Microsoft documents the tell on its SQL Server 2025 Known Issues page: the startup error log shows the line "Using locked pages in the memory manager" where, on the same hardware running an earlier Windows Server release, it either didn't appear or didn't precede a crash. That single log line is the fastest way for an admin to check exposure without waiting for a dump to land.

RelatedMicrosoft's Project Zenith Reboots Windows for AI Developers

How the Windows Server 2025 LPIM bug crashes SQL Server Diagram showing two conditions combining to crash SQL Server: an instance running with Lock Pages in Memory enabled, and Windows Server 2025's changed AWE memory manager. Together they trigger an access violation, error 0xC0000005, for which Microsoft has documented a workaround but no permanent fix. WHY SQL SERVER CRASHES ON WINDOWS SERVER 2025 SQL SERVER Lock Pages in Memory policy: enabled WINDOWS SERVER 2025 AWE memory manager behavior changed ACCESS VIOLATION 0xC0000005 crash dump, no fix shipped yet genztech.blog
Fig 1 Neither condition alone causes the crash. LPIM has shipped safely for years, and Windows Server 2025 runs fine for workloads that don't lock pages. It's the combination Microsoft didn't catch before release.

Why does a memory-protection setting cause a crash at all?

LPIM exists to stop Windows from paging a SQL Server instance's buffer pool out to disk when the OS comes under memory pressure. For a database server with a large, expensive-to-rebuild cache, that's a meaningful reliability win, which is exactly why Microsoft has recommended it in its own SQL Server hardware and performance guidance for years. To get that guarantee, SQL Server uses Address Windowing Extensions (AWE), an older Windows API for mapping physical memory directly rather than through the normal virtual-memory path. Windows Server 2025 changed how its memory manager handles AWE-locked pages, and that change is what Microsoft says now produces access violations under certain configurations. Nothing about SQL Server's own code changed. The floor it was standing on moved.

Who's actually exposed?

Any SQL Server instance where an admin has turned on LPIM for the service account, running on Windows Server 2025, whether that's a fresh deployment or a server that got upgraded from an older Windows Server release. Microsoft's language is broad enough to matter beyond SQL Server too: it frames this as an AWE memory-management change, not a SQL-Server-specific one, which means other software that locks pages through the same API could theoretically hit the same access violation. Microsoft's public writeup only documents the SQL Server case so far. There's an uncomfortable irony here for database admins: following Microsoft's own long-standing performance advice is the thing that puts a server at risk on its newest OS.

Is there a fix?

Not yet. Microsoft's documented workaround is to disable the LPIM policy for the SQL Server service account, which removes the crash condition but also removes the protection LPIM was there for: under memory pressure, the buffer pool can get paged out, and Microsoft's own known-issues page warns this may hurt SQL Server's memory and performance behavior. Microsoft says it is "investigating a fix for a future release of Windows Server 2025." No KB number has been assigned; the issue lives as an entry on the SQL Server 2025 Known Issues page, last updated August 25, 2026, rather than as a standalone patch. BleepingComputer's report, published today, is what's putting the issue in front of IT admins who don't routinely comb Microsoft's known-issues documentation.

RelatedMicrosoft Pauses Windows 11 Update Over Dell Shutdowns

  1. Since GAWindows Server 2025 ships AWE memory-manager behavior changes from prior releases
  2. Aug 25, 2026Known issue documented Microsoft adds the LPIM access-violation entry to its SQL Server 2025 Known Issues page
  3. Sep 8, 2026Wider coverage BleepingComputer reports on the documented issue, no fix yet
  4. TBDPatch Microsoft has not committed to a release date for a permanent fix
What to watch
  • Whether Microsoft assigns a KB and a release date. Right now this sits as a known-issue note with no committed timeline, which is a weaker signal than a scheduled cumulative update.
  • Whether the bug turns out to be broader than SQL Server. Any other AWE-dependent enterprise software on Windows Server 2025 with LPIM enabled is worth checking for the same "Using locked pages in the memory manager" log line and access-violation signature.
  • Whether admins quietly disable LPIM fleet-wide. That's the safe move today, but it trades a known crash risk for an unmeasured performance regression under memory pressure, which is its own operational bet.

Our take

The part worth sitting with is that the "fix" right now is to turn off a setting Microsoft itself has been telling database admins to turn on. That's not a great place for a production database platform to be, even as a temporary state. It also says something about how Windows Server 2025's rollout has gone: this is a foundational memory-management change surfacing a real crash more than a year after the OS's initial release, in a configuration common enough that Microsoft's own SQL Server team had to document it. Admins running SQL Server on Windows Server 2025 should check for that log line today rather than wait for a KB number that doesn't exist yet.

Primary sources

Original analysis by GenZTech, based on Microsoft's own known-issues documentation and BleepingComputer's reporting. Source