[UPDATED] In March 2026, our production messaging-database cluster started crashing again. Same exception code as the incident we resolved last year (0xc0000005, Access Violation), but a different stack signature, different servers, different cloud, and ultimately a completely different root cause. This time the bug wasn't in SQL Server. It wasn't in the storage drivers. It wasn't in our queries. It was in something we'd never have suspected without comparing the crashing ser

In late October 2025, our production SQL Server 2022 Enterprise cluster running on AWS EC2 started crashing repeatedly with Access Violation (0xc0000005) exceptions. This wasn't just any database going down — this cluster is the heart of the business. It powers the core platform that our customers depend on every day: real-time communications services, call routing, messaging, and the APIs that integrate with everything downstream. When this database cluster goes offline, the

It was a regular Thursday afternoon. The kind where you're wrapping up tasks, maybe thinking about what to have for dinner. And then, at 4:36 PM, the alerts started rolling in. Transaction processing delays. Partial database inaccessibility. The production database cluster — the one that powers core services for an entire region — was going down. Not because of a hardware failure. Not because someone fat-fingered a config change. But because of something far more subtle: a gh

How default SQL Server configuration brought a production server to its knees — and how two settings fixed it in under a minute. The Escalation It started with a message from my manager: Attached was a screenshot of CPU pinned near 100%. Not a good look on a production server handling live traffic. The Investigation My first instinct was to hunt for a rogue query. That's usually the culprit — some poorly optimized SELECT statement doing a full table scan, or a report running