SQL Server Check

Memory dumps

This is one of many SQL Server checks performed by our free sp_Check tools.

Learn More About Our sp_check Tools

Checks Performed

ID
Check
629
memory dumps

What’s the issue?

A stack dump is a diagnostic file that SQL Server generates automatically when it encounters a serious internal error, such as an access violation, an assertion failure, or an unhandled exception within the database engine. The dump file captures the state of the SQL Server process at the moment of failure, including thread information, memory contents, and the call stack, and is written to the SQL Server LOG directory along with corresponding entries in the error log. This finding indicates that one or more stack dumps have been generated on the instance.

Why is this a problem?

Stack dumps are not normal. They indicate that SQL Server hit a condition the engine was not designed to handle gracefully, which is almost always a sign of something seriously wrong. Possible causes include software bugs in SQL Server itself, hardware problems such as failing memory or storage, corruption in databases or system metadata, faulty drivers, or interference from third party software such as antivirus or filter drivers. Some stack dumps are isolated incidents, but recurring dumps often precede broader stability problems including service crashes, data corruption, or extended outages. Ignoring stack dumps means missing the early warning signs of failures that may escalate.

What should you do about this?

Locate the dump files in the SQL Server LOG directory (typically named SQLDump####.txt and .mdmp) and review the SQL Server error log around the timestamps of each dump to identify what was happening when the failure occurred. Note any patterns such as specific queries, jobs, features, or times of day that correlate with the dumps. Apply the latest cumulative update or service pack for your SQL Server version, since many stack dump conditions are fixed bugs that have already been patched.

Run DBCC CHECKDB on all databases to rule out corruption, and verify hardware health by reviewing Windows event logs, running memory diagnostics, and checking storage subsystem reports. If dumps continue after patching and hardware checks, open a support case with Microsoft and provide the dump files along with the error log, since detailed analysis of the dump contents typically requires Microsoft’s internal symbols.

Read more…

Non-Yielding Scheduler During Backups? – Opinionated SQL

Type

Reliability

Importance

Low

sp_Checks