SQL Server 2019 Many No Longer Capture Mini-Dump (SQLDump####.mdmp)
Published Feb 21 2022 10:02 AM 2,244 Views
Moved from: bobsql.com


I was looking at a SQL Server which had generated ten(10) SQLDump####.txt files but only a single(1) SQLDump####.mdmp file.  We introduced a new feature in SQL Server 2019 to save disk space for mini/crash dumps which can skip the suspension and capture for identical dump signatures, saving disk space and reducing the impact on the SQL Server instance.


  • Each time the SQL Server instance is started a hash table is created to track crash dump signatures.
  • The first time a crash dump signature is encountered a SQLDump####.mdmp is created and the signature is stored in the hash table.
  • The decision to create a mini-dump performs a hash table lookup using the crash signature.  When the signature is present the second, third, … mini-dumps are skipped.

The SQLDump####.txt file is generated with limited information and then an entry is logged in the SQL Server error log to indicate the mini-dump is being skipped.


The SQL Server error log will contain the basic crash information such as the following.


2019-11-02 04:35:08.05 spid105s    ***Stack Dump being sent to /var/opt/mssql/log/SQLDump0010.txt
2019-11-02 04:35:08.05 spid105s    *
2019-11-02 04:35:08.05 spid105s    * BEGIN STACK DUMP:
2019-11-02 04:35:08.05 spid105s    *   11/02/19 04:35:08 spid 105
2019-11-02 04:35:08.05 spid105s    *
2019-11-02 04:35:08.05 spid105s    * Location: cmedobj.cpp:7422
2019-11-02 04:35:08.06 spid105s    * Expression:     HKTIK_Primary !=
tableIdKind || PCXCtxtB()->PXLvlIntCtxt()->FInUpgrade()
2019-11-02 04:35:08.06 spid105s    * SPID:            105
2019-11-02 04:35:08.06 spid105s    * Process ID:     40
2019-11-02 04:35:08.06 spid105s    *
2019-11-02 04:35:08.06 spid105s    *  MODULE                          BASE      END       SIZE
2019-11-02 04:35:08.06 spid105s    * sqlservr                       0000001080240000  00000010802DDFFF  0009e000
2019-11-02 04:35:08.17 spid105s    *
2019-11-02 04:35:08.17 spid105s    *     P1Home: 0000000100000010: 2019-11-02 04:35:08.17 spid105s    *     P2Home: 000000006BF543C3:
2019-11-02 04:35:08.20 spid105s    * Short Stack Dump
2019-11-02 04:35:08.22 spid105s    0000001082B202B8 Module(KERNELBASE+00000000000402B8)
2019-11-02 04:35:08.22 spid105s    00000010871ED93E Module(sqllang+0000000000F7D93E)
2019-11-02 04:35:08.22 spid105s    00000010871F18CA Module(sqllang+0000000000F818CA)
At the end of the crash information the dump signature is logged.

2019-11-02 04:35:08.31 spid105s    Stack Signature for the dump is 0x0000000198EAD992

If the signature has already generated a mini-dump a message is logged indicating dismissal of the attempt.

2019-11-05 16:03:05.32 spid29s     Dump request is dismissed (stack signature 0x0000000198EAD992).

Using the signature logged in the message you are able to locate the initial SQLDump####.mdmp for further troubleshooting.

For troubleshooting be sure to keep all the error logs and SQLDump* files generated from the time the SQL Server instance starts until it stops.  The group of files represents the lifetime of the hash table and dump generation captures.


Skipping the mini-dump reduces the disk space as no SQLDump####.mdmp is saved.  Skipping also has the benefit of avoiding the dbghelp thread suspension activities used to capture a dump.  Without suspend activities the impact on the SQL Server process is reduced.


You can disable the behavior by enabling trace flag (2553) and force the dump to be captured for each occurrence.

Dynamically: dbcc traceon(2553,-1)
Server startup parameter: -T2553

Version history
Last update:
‎Feb 21 2022 10:02 AM
Updated by: