SQL Server 128: Severe Error Fix Steps (Severity 20)

Quick Answer

If you're in a hurry, run DBCC CHECKDB on the affected database and check the SQL Server error log for the underlying stack dump—often it's a corrupted page or a driver issue. Then restart SQL Server if the error persists.

That's the blunt fix. But if you've seen this error more than once, you already know it's never that simple. Error 128 with severity 20 is a serious internal failure—the command dies mid-stream, and SQL Server tells you to throw away any partial results. It's not a syntax error or a permission problem. Something underneath the query broke.

I've seen this error pop up in two common scenarios. First, when a query hits a corrupted page in the buffer pool. Second, during heavy parallelism where memory grants go sideways, often after a Windows update or a change in max server memory. The error log is your best friend here—it'll show a stack dump pointing to the exact module.

The Numbered Fix Steps

Check the SQL Server error log – Open SQL Server Management Studio, go to Management > SQL Server Logs, and look for entries around the time of the error. You'll likely see a stack dump with a module name like sqllang.dll or ntdll.dll. That tells you where to look next.
Run DBCC CHECKDB on the database – Run this in a query window:
```
DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS, ALL_ERRORMSGS;
```
If it finds corruption, you'll need to restore from a clean backup. Don't skip this step—I've seen people spend hours tweaking settings only to find a bad page was the culprit.
Set a fixed max server memory – If the error appears under load, check your memory settings. Run:
```
EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'max server memory (MB)', 8192; -- adjust to your RAM RECONFIGURE;
```
Leaving it at default lets SQL Server gobble memory until the OS fights back, which can trigger severe errors.
Cap MAXDOP if it's high – Parallel queries with too many threads can hit internal timeouts and throw error 128. Set MAXDOP to 4 or less on most systems:
```
EXEC sp_configure 'max degree of parallelism', 4; RECONFIGURE;
```
Update the SQL Server version – Microsoft has fixed several error 128 bugs in cumulative updates. Check your version with SELECT @@VERSION and compare against the latest service pack or CU.

When the Main Fix Fails

If DBCC CHECKDB comes back clean and the error persists, the problem might be outside the database. Try these in order:

Test with a different client – Run the same query from sqlcmd or a different SSMS version. I've seen ODBC driver bugs cause this. If it works from sqlcmd, update your client drivers.
Disable the query plan – Sometimes a bad cached plan triggers the error. Use DBCC FREEPROCCACHE to clear it, then rerun the query. If it works, you've got a plan issue—consider adding OPTION (RECOMPILE) to the query.
Check for antivirus interference – Antivirus scanning tempdb or data files can cause severe errors. Exclude SQL Server directories from real-time scanning. This is more common than you'd think.
Look at disk I/O errors – Check the Windows Event Viewer for disk errors. If your disk is failing, SQL Server might throw error 128 when reading pages. Run chkdsk if you suspect this.

Prevention That Actually Works

The best way to avoid error 128 is to keep your server balanced. Set a fixed memory limit, keep MAXDOP reasonable, and install cumulative updates on a regular schedule—don't wait months between them. Also, set up a job that runs DBCC CHECKDB weekly. Most corruption is silent until a query hits it, and catching it early beats a midnight outage. I know this error is infuriating, especially when you're in the middle of a deadline. But with the error log and a few commands, you'll isolate it faster than you think.

Remember, severity 20 errors are not about your query's logic. They're a cry for help from the engine itself. Treat them with respect, and you'll keep your databases healthy.