How to use the Sqldumper.exe utility to generate a dump file in SQL Server

Applies to: SQL Server 2012 StandardSQL Server 2012 EnterpriseSQL Server 2012 Developer


The Sqldumper.exe utility is included with Microsoft SQL Server. This article describes how to use the Sqldumper.exe utility to generate a dump file for Watson error reporting or for debugging tasks.

In addition to the Sqldumper.exe utility, the following methods are also available:

Warning Generating process dump files can affect Service Availability (here SQL Server) and trigger resources failovers in Always On contexts (both Failover Cluster Instance and Availability Group). The options that are used to generate the dump files will make a large difference. Make sure that you read the Impact of Dump Generation and Dump Types sections.

When you capture a SQL Server process dump file (especially a filtered dump file or a full dump file) on a clustered SQL Server or a SQL Server hosting an AlwaysOn Availability Group (AG) instance, the clustered SQL Server or AG may fail over to another node if the dump file takes too long to be completed. To avoid the potential failover, you can use the following settings before you capture the dump file, and you can revert the change back after a dump file is taken:

  • For clustered SQL Server (FCI), right-click SQL Server resource in Cluster Administrator, select "If resource fails, do not restart" on the Policies tab.
  • For AG, apply all the following settings:
    • Increase Session-Timeout, for example, 120 seconds for all replicas. In SQL Server Management Studio, right-click the replica to be configured, and then click Properties. Change Session-Timeout (seconds) field to 120 seconds. For more information, see Change the Session-Timeout Period for an Availability Replica (SQL Server).
    • Change the "auto failover" of all replicas to "manual failover". In SQL Server Management Studio, right-click replica, select Properties, and then change the "auto failover" of all replicas to "manual failover" on the Properties tab. For more information, see Change the Failover Mode of an Availability Replica (SQL Server).
    • Increase the "LeaseTimeout" to 60,000 ms (60 seconds) and change HealthCheckTimeout to 90,000 ms (90 seconds). In Cluster Administrator, right-click AG resource, select Properties, and then switch to the Properties tab to modify both settings. For more information, see Configure HealthCheckTimeout Property Settings.

More Information

How to run the Sqldumper.exe utility Manually

Run the Sqldumper.exe utility under the context of the folder where SQL Server originally installed the utility. By default, the installation path of the Sqldumper.exe utility is as follows:

SQLServerInstallDrive:\Program Files\Microsoft SQL Server\90\Shared\SQLDumper.exe

Note SQLServerInstallDrive is a placeholder for the drive where you installed SQL Server 2005.

To generate a dump file by using the Sqldumper.exe utility, follow these steps:
  1. Open the following folder:

    SQLServerInstallDrive:\Program Files\Microsoft SQL Server\number\Shared

    In this folder path, number is a placeholder for one of the following:
    • 140 for SQL Server 2017
    • 130 for SQL Server 2016
    • 120 for SQL Server 2014
    • 110 for SQL Server 2012
    • 100 for SQL Server 2008
    • 90 for SQL Server 2005
  2. Make sure that the Dbghelp.dll file is in this folder.
  3. Click Start, click Run, type cmd, and then click OK.
  4. At the command prompt, type the following command, and then press ENTER:

    cd SQLServerInstallDrive:\Program Files\Microsoft SQL Server\number\Shared

    Note In this folder path, number is the same placeholder changing with SQL Server version as described earlier.
  5. To generate a specific kind of dump file, type the corresponding command at the command prompt, and then press ENTER:
    • Full dump file
      Sqldumper.exe ProcessID 0 0x01100
    • Mini-dump file
      Sqldumper.exe ProcessID 0 0x0120
    • Mini-dump file that includes indirectly referenced memory. This is the recommended option and is also used by SQL Server by default when auto-generating memory dumps
      Sqldumper.exe ProcessID 0 0x0128
    • Filtered dump file
      Sqldumper.exe ProcessID 0 0x8100
    Note ProcessID is a placeholder for the process identifier of the Windows application for which you want to generate a dump file.
If the Sqldumper.exe utility runs successfully, the utility generates a dump file in the folder where the utility is installed.

The dump file that the Sqldumper.exe utility generates has a file name pattern that resembles the following:
In this pattern, xxxx is an increasing number that is determined based on other files that have a similar file name in the same folder. If you already have files in the folder that have file names in the specified pattern, you may have to compare the date and the time that the file was created to identify the file that you want.

Additional information and considerations

SQLDumper.exe exists primarily to generate memory dumps for the SQL Server process in scenarios where a memory dump is needed to resolve specific problems (exceptions, asserts, non-yielding schedulers, etc.). In such cases SQL Server invokes the SQLDumper.exe to generate a memory dump of its process. The memory dump is stored in a path configured in the SQL Server Configuration Manager with a default location MSSQL\LOG\ directory.  If in some cases the dump size is too large, for example, you can modify the path by doing the following: 

  1. Open SQL Server Configuration Manager
  2. Under SQL Server Services locate the SQL Server under investigation
  3. Right-click on it, choose Properties and go to the Advanced tab
  4. Modify that Dump Directory to the desired path and click OK
  5. Restart SQL Server (when possible) for the new setting to take effect.

When the Sqldumper.exe utility is used manually to generate a dump file for any Windows application, the dump file may be as large as the memory that the Windows application is currently using. Make sure that sufficient disk space is available on the drive to which the Sqldumper.exe utility is writing the dump file.

You can specify the directory where you want the Sqldumper.exe utility to write the dump file. The directory must already exist before you run the Sqldumper.exe utility. Otherwise, the Sqldumper.exe utility will fail. Do not use a UNC path as a location for the dump file. The following is an example of how to specify the dump file location of the mini-dump file:

  1. Click Start, click Run, type cmd, and then click OK.
  2. At the command prompt, type the following command, and then press ENTER:
    cd SQLServerInstallDrive:\Program Files\Microsoft SQL Server\number\Shared
    Note In this folder path, number is a placeholder for one of the following:
    • 140 for SQL Server 2017
    • 130 for SQL Server 2016
    • 120 for SQL Server 2014
    • 110 for SQL Server 2012
    • 100 for SQL Server 2008
    • 90 for SQL Server 2005
  3. Type the following command at the command prompt, and then press ENTER:

    Sqldumper.exe ProcessID 0 0x0128 0 MdumpPath

    MdumpPath is a placeholder for the directory where you want the Sqldumper.exe utility to write the dump file. By default, the file is written to the current folder.
If you specify a full dump file or a filtered dump file to be generated, the Sqldumper.exe utility may take several minutes to generate the dump file. The time depends on the following variables:
  • The amount of memory that the Sqldumper.exe utility is currently using
  • The speed of the drive to which the utility is writing the dump file

During this time, the Sqldumper.exe utility will not process commands. You will notice that the server has stopped responding. Additionally, a cluster failover may occur.

To run the Sqldumper.exe utility, you must log on to Windows by using one of the following methods:

  • Use an account that is a member of the administrators group on the computer.
  • Use the same user account under which the SQL Server service is running.
For the Sqldumper.exe utility to work successfully through Remote Desktop or through Terminal Services, you must start Remote Desktop or Terminal Services in console mode. For example, to start Remote Desktop in console mode, click Start, click Run, type mstsc /console, and then click OK. Be aware that if the target server runs Windows 2000, the /console option is silently ignored. You can connect to the server through Remote Desktop. But you will not be using the console session.
If you notice that no dump file has been generated in the current folder after you run the Sqldumper.exe utility, review the information that the utility has generated at the command line to try to determine the possible cause of the failure. This information is also logged in the Sqldumper_errorlog.log file in current directory. The following are two possible error messages and their causes:
Message 1
OpenProcess failed 0x57 - The parameter is incorrect

An invalid Process ID was passed to the Sqldumper.exe utility.
Message 2
Invalid value for thread id - <invalid parameter> Parameter error

An invalid parameter was passed to the Sqldumper.exe utility.

If an error message that resembles one of the following is generated, you can safely ignore this message:
Unknown callback type during minidump 6
Unknown callback type during minidump 7

Impact of Dump Generation

When a dump of a user-mode process is requested (as is discussed in this article, to be contrasted with Operating System Kernel Dumps which are outside our scope), the target Process (here SQLServer.exe) is completely frozen for the duration it takes to serialize the dump content to its file target.

Frozen means that it will be unable to process any user request or progress any internal operation, including any Resource Polling mechanism like the implementation of Windows Clustering's IsAlive and LooksAlive (see the 'Cluster failovers and the Sqldumper.exe utility' section for details on handling that situation). Any time-out relying on wall clock time may also be breached as a consequence of the freeze.

As can be derived from the previous statement, the duration of the freeze is therefore the critical factor here, and it is mainly driven by the following:

  • The type of dump selected
  • The size of SQL Server process in memory, which in the case of a single active instance running default parameters is often close to the total physical RAM of the server.
  • The performance of the disk used as a target for the dump.

Furthermore, the size of the dump file on disk should be planned for, especially if multiple dumps are a possibility and if large, non-default dump types are selected. Make sure you review the 'Dump Types' section to know what to expect. By default, some dump methods will create the dump in SQL Server Instance's \Log folder, which, in default simple configuration would also be system disk and data+log disk for SQL Server. Bringing that disk to saturation will have severe impact on SQL Server and/or system availability.

Three major improvements have been added to recent versions of SQL Server to reduce the size of the dump file and/or time for generating the memory dump:
  • Bitmap filtering mechanism
  • Elimination of repeated dumps on the same issue
  • Shortened output in the Errorlog

Bitmap Filtering: Improved filtered dump speed and reduced size has been achieved due to a new bitmap filtering mechanism that has been added to SQL Server 2019 and SQL Server 2017.
SQL Server allocates a bitmap that keeps track of memory pages to be excluded from a filtered dump. Sqldumper.exe reads the bitmap and filters out pages without the need to read any other memory manager metadata. You will see the following messages in the SQL Server Errorlog when the bitmap is enabled or disabled respectively: " Page exclusion bitmap is enabled." and "Page exclusion bitmap is disabled."

SQL Server 2016

  • Starting with SQL Server 2016 SP2 CU13 the bitmap filtering is enabled by default.

SQL Server 2017

  • This is not available in RTM through CU15
  • In SQL Server 2017 CU16 you can enable the bitmap filtering via T8089 and disable it by turning off T8089
  • Starting with SQL Server 2017 CU20 the bitmap filtering is enabled by default. Trace flag T8089 will no longer apply and will be ignored if turned on. The bitmap filtering can be disabled via T8095.

SQL Server 2019

This is enabled by default in SQL Server 2019 RTM. It can be disabled via T8095.

Elimination of repeated dumps on the same issue:  Repeated memory dumps on the same problem are now eliminated. Using a stack signature, the SQL engine keeps track if an exception has already occurred and will not produce a new memory dump if there is one already. This applies to access violations, stack overflow, asserts, and index corruption exceptions. This significantly reduces the amount of disk space used by memory dumps and does not freeze the process temporarily to generate a dump. This was added in SQL Server 2019.
Shortened output in the Errorlog: The content generated in the SQL Server Errorlog from a single memory dump cannot only be overwhelming, but it also slowed down the process of generating a memory dump due to the time all this information had to be serialized into a text format in the Errorlog. In SQL Server 2019, the content stored in the Errorlog upon dump generation has been greatly reduced and it may look like this:
DateTime spidSpid    **Dump thread - spid = 0, EC = 0x0000015C7169BF40
DateTime spidSpid    *
DateTime spidSpid    *User initiated stack dump. This is not a server exception dump.
DateTime spidSpid    *
DateTime spidSpid    Stack Signature for the dump is 0x00000000788399E5
DateTime spidSpid    External dump process return code 0x20000001.
External dump process returned no errors.

Previously SQL Server would print information for each session/thread when a manual dump was triggered by the user for example. 

Dump Types

The methods described are able to generate three different types of dumps: mini dumps, full dumps, and filtered dumps.

Mini dumps with referenced memory are a snapshot of all active threads of the process ("thread stacks"), along with a limited extract of the memory referenced by the thread stacks and some other key process/thread data. They are typically a few megabytes in size, and are very fast to generate (from less than a second to a couple of seconds). Even larger server systems (with hundreds of CPU indirectly driving massive number of threads in SQL Server process) will rarely exceed 20-30 MB: the size of a mini dump doesn't grow with the size of SQL Server process. This dump type is the default type used by SQL Server when generating memory dumps automatically on exceptions, scheduler issues, latch issues, etc.

Note that SQL Server, as part of its built-in instrumentation, will generate automated "diagnostic mini dumps" in some specific situations. This operation is therefore considered safe enough that SQL Server can trigger it automatically when needed.

Full dumps are a complete copy of the active target process space. That would therefore include all thread state, all process allocated memory, and all loaded modules. Full dumps will therefore have a size which is roughly the same of SQL Server process, which in turn may be almost as large as total system RAM. On large servers dedicated to a single SQL Server instance, that might mean a file which is several hundreds of gigabytes or more. Needlessly to say, such a file will take a long time to generate and will therefore induce prolongated freeze. Disk performance for file target of dump will be a major driver to freeze time. Note that this kind of dump is very rarely used for SQL Server today, as next type description will explain.

Filtered dumps: As the RAM size of typical servers running SQL Server has steadily increased, full dumps became more and more unwieldy. Filtered dumps were therefore implemented: they are a subset of full dumps, where large areas of memory structures pertaining to SQL Server are purposefully ignored and not serialized to disk as they bring no troubleshooting added value (typically, data/index pages, some internal caches like Hekaton data pages and Log Pool memory). This results in a file which is smaller than a full dump while retaining almost all its usefulness, and this has replaced full dumps as preferred option in a vast majority of situations where mini dumps were not sufficient. The size decrease vs full dump can vary a lot, but it still a rather large file which is often 30-60 % of SQL Server process size, so it's best to plan for a possible size as large as a full dump as a worst option, which should leave a good safety margin. Note that a filtered dump may not be necessarily faster to generate than a full dump in every case: it's a matter of whether the gains tied to the number of IO avoided exceed the time required to implement the filter logic (so disk speed and CPU/RAM speed will influence that).

You can use the Sqldumper.exe utility to generate a dump file on demand for any Microsoft Windows application. For example, you can generate a dump file for debugging an application problem when a computer that is running Microsoft SQL Server is not responding to user requests. A dump file can be a mini-dump file or a full dump file. A filtered dump file is only applicable and meaningful in the context of SQL Server.

However, you cannot use the Sqldumper.exe utility for general purpose debugging. For more information about general purpose debugging, visit the following Microsoft Web site:

The SQL Server process calls the Sqldumper.exe utility internally to generate a dump file when the process experiences any exceptions. SQL Server passes flags to the Sqldumper.exe utility. You can use trace flags to change the flags that SQL Server passes to the utility in the context of an exception or in the context an assertion. These trace flags are in the range from 2540 to 2559. You can use these trace flags to generate certain types of dump files. For example:

  • Trace Flag 2551: Produces a filtered memory dump
  • Trace Flag 2544: Produces a full memory dump
  • Trace Flag 8026: SQL Server will clear a dump trigger after generating the dump once

If two or more trace flags are active, the option indicating the largest memory dump will be honored. For example, if trace flags 2551 and 2544 are used, SQL Server will create a full memory dump.

How to obtain a Microsoft Windows application process identifier

To generate a dump file by using the Sqldumper.exe utility, you must have the process identifier of the Windows application for which you want to generate a dump file. To obtain the process identifier, follow these steps:

  1. Press CTRL+ALT+DELETE, and then click Task Manager.
  2. In the Windows Task Manager dialog box, click the Processes tab.
  3. On the View menu, click Select Columns.
  4. In the Select Columns dialog box, click to select the PID (Process Identifier) check box, and then click OK.
  5. Notice the process identifier of the Windows application for which you want to generate a dump file. For the SQL Server application, notice the process identifier of the Sqlservr.exe process.
  6. Close Task Manager.

You can also obtain the process identifier of the SQL Server application that is running on your computer by using the SQL Server error log file. For example, part of the SQL Server error log file resembles the following:

Date/Time Server Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86)


Copyright (c) 1988-2005 Microsoft Corporation

Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 1)

Date/Time Server (c) 2005 Microsoft Corporation.

Date/Time Server All rights reserved.

Date/Time Server Server process ID is 3716.

The number that appears after Server process ID is the process identifier for the Sqlservr.exe process.

Cluster failovers and the Sqldumper.exe utility

In cluster failover scenarios, the SQL Server resource DLL now can obtain a dump file before the failover occurs. When the SQL Server resource DLL determines that a SQL Server resource has failed, the SQL Server resource DLL uses the Sqldumper.exe utility to obtain a dump file of the SQL Server process. To make sure that the Sqldumper.exe utility successfully generates the dump file, you must set the following three properties as prerequisites:
  • SqlDumperDumpTimeOut
    A user-specified time-out. The resource DLL waits for the dump file to be completed before the resource DLL stops the SQL Server service.
  • SqlDumperDumpPath
    The location where the Sqldumper.exe utility generates the dump file.
  • SqlDumperDumpFlags
    Flags that the Sqldumper.exe utility uses.

If any one of the properties is not set, the Sqldumper.exe utility cannot generate the dump file. A warning message will be logged both in the event log and in the cluster log whenever the resource is brought online.

For SQL Server 2012 and later

You can use the ALTER SERVER CONFIGURATION (T-SQL) command to modify these properties. For example:




Alternatively, you can use PowerShell scripts. For example for a named instance SQL2017A:

Get-ClusterResource -Name "SQL Server (SQL2017AG)" | Set-ClusterParameter -Name "SqlDumperDumpPath" -Value "C:\temp"

Get-ClusterResource -Name "SQL Server (SQL2017AG)" | Set-ClusterParameter -Name "SqlDumperDumpFlags" -Value 296

Get-ClusterResource -Name "SQL Server (SQL2017AG)" | Set-ClusterParameter -Name "SqlDumperDumpTimeOut" -Value 0

To validate the settings have been applied, you can run this PowerShell command:

Get-ClusterResource -Name "SQL Server (SQL2017AG)" | Get-ClusterParameter

For SQL Server 2008/2008 R2 or Windows 2012 and earlier


The DBCC STACKDUMP command can help you create a memory dump in the LOG directory of your SQL Server instance installation. The command will by default create a minidump with all threads which has limited size and is adequate to reflect the state of SQL Server process. Simply execute the following command in a SQL Server client:


To enable this method to create a filtered dump, turn on trace flags 2551 with following command:

dbcc traceon(2551, -1) godbcc stackdump

To create a full dump, use trace flag 2544.

Note After you get the dump file, you should disable the trace flag by using the following command to avoid inadvertently upgrading all further SQL Server self-diagnostic minidumps to larger dumps:

DBCC TRACEOFF (TraceNumber, -1);   GO

Where tracenumber is the trace flag you have previously enabled like 2551 or 2544.

In case you are unsure of which trace flag remains active, you can execute:


An empty result set indicates no traceflag is active. Conversely, if 2551 is still active you would see:

TraceFlag Status Global Session

--------- ------ ------ -------

2551      1      1      0

Note The traceflags enabled by DBCC TRACEON are reset (removed) after a service restart.

How to use a Powershell script to generate a dump file with SQLDumper.exe

  • Save the following code as a ps1 file, for example SQLDumpHelper.ps1:
  • Run it from Command Prompt as Administrator by using the following command:
    Powershell.exe -File SQLDumpHelper.ps1
  • Or run it from Windows PowerShell console and run as Administrator by using the following command:

Note If you have never executed PowerShell scripts on your system, you may receive the following error message:

File …SQLDumpHelper.ps1 cannot be loaded because running scripts is disabled on this system.

You have to enable the ability to run them by the following steps:

  1. Start Windows PowerShell console with the "Run as Administrator" option. Only members of the Administrators group on the computer can change the execution policy.
  2. Enable running unsigned scripts by the following command:
    Set-ExecutionPolicy RemoteSigned

    Note This will allow you to run unsigned scripts that you create on your local computer and signed scripts from Internet.