SQL Agent job step "Dump on errors" produces no output

Question

SQL Agent job step "Dump on errors" produces no output

Peter Bishop 256

I have a SQL Server Integration Services Package agent job step that is failing with an "Unexpected termination". To help diagnose what's going on, I've selected the "Dump on errors" flag of the Configuration/Advanced tab.

However when the package fails, no dump file is created.

Is there a global parameter I need to configure to enable the "Dump on errors" option to work or is something else going on here?

Thanks.

Senthil kumar 2,420 Reputation points

2026-06-17T08:38:17.73+00:00

Hi @Peter Bishop

try this option may be SSIS support 32 bit so try this.

Job Step → Execution Options → Use 32‑bit runtime.

Thanks.
David Yard 0 Reputation points

2026-06-17T14:11:44.72+00:00
This caught me off guard the first time too. The most common reason no dump file is created is that the target folder either does not exist or the SQL Server Agent service account does not have write access to it. Check that first before anything else.

The default dump location is:

C:\Program Files\Microsoft SQL Server\<instance>\Shared\ErrorDumps

Grant the Agent service account full write access to that folder. If the folder does not exist create it manually and then set the permissions.

You can also confirm where SQL Server is actually configured to write dumps:

sql

EXEC xp_instance_regread N'HKEY_LOCAL_MACHINE', N'SOFTWARE\Microsoft\Microsoft SQL Server\<InstanceName>\CPE', N'SqlDumpDir';

The other thing worth knowing is that Dump on errors only fires on managed SSIS errors. If the package is terminating unexpectedly due to an out-of-memory condition, a process crash, or an external dependency failure, the dump mechanism is bypassed entirely and nothing gets written. Check the Windows Event Log at the exact time of failure. That will often tell you more than the SSIS logs in these cases.

Also make sure the target volume has available disk space. A full disk causes the dump to silently fail with no notification.
Anonymous

2026-06-25T12:04:26.5966667+00:00

Hi @Peter Bishop ,

Thank you for the update. Since the package runs successfully under a sysadmin account but fails when executed by the SQL Agent service account, this points more toward a security or execution-context issue than a problem with the "Dump on errors" option itself. I'd recommend comparing the SQL Agent service account's permissions with your interactive login, including access to any file shares, temp folders, and external resources used by the package. The inconsistent failures with larger result sets also suggest the Agent account may be encountering a permission or resource limitation that isn't present when you run the package manually.

Thanks,
Akhil.
Erland Sommarskog 137.4K Reputation points MVP Volunteer Moderator

2026-06-25T19:22:35.8866667+00:00

Thank you for the update. Since the package runs successfully under a sysadmin account but fails when executed by the SQL Agent service account,

Well, the service account for SQL Server Agent is a member of the sysadmin role in SQL Server. But this is obviously not a matter of SQL Server permissions, but permissions in Windows.

As for the issue as such, I don't have much to offer, since I don't know much about SSIS. But David Yard's post seems interesting.

2 answers

Your answer

Senthil kumar 2,420 Reputation points

2026-06-17T08:38:17.73+00:00

Hi @Peter Bishop

try this option may be SSIS support 32 bit so try this.

Job Step → Execution Options → Use 32‑bit runtime.

Thanks.
David Yard 0 Reputation points

2026-06-17T14:11:44.72+00:00

This caught me off guard the first time too. The most common reason no dump file is created is that the target folder either does not exist or the SQL Server Agent service account does not have write access to it. Check that first before anything else.

The default dump location is:

C:\Program Files\Microsoft SQL Server\<instance>\Shared\ErrorDumps

Grant the Agent service account full write access to that folder. If the folder does not exist create it manually and then set the permissions.

You can also confirm where SQL Server is actually configured to write dumps:

sql

EXEC xp_instance_regread N'HKEY_LOCAL_MACHINE', N'SOFTWARE\Microsoft\Microsoft SQL Server\<InstanceName>\CPE', N'SqlDumpDir';

The other thing worth knowing is that Dump on errors only fires on managed SSIS errors. If the package is terminating unexpectedly due to an out-of-memory condition, a process crash, or an external dependency failure, the dump mechanism is bypassed entirely and nothing gets written. Check the Windows Event Log at the exact time of failure. That will often tell you more than the SSIS logs in these cases.

Also make sure the target volume has available disk space. A full disk causes the dump to silently fail with no notification.
Anonymous

2026-06-25T12:04:26.5966667+00:00

Hi @Peter Bishop ,

Thank you for the update. Since the package runs successfully under a sysadmin account but fails when executed by the SQL Agent service account, this points more toward a security or execution-context issue than a problem with the "Dump on errors" option itself. I'd recommend comparing the SQL Agent service account's permissions with your interactive login, including access to any file shares, temp folders, and external resources used by the package. The inconsistent failures with larger result sets also suggest the Agent account may be encountering a permission or resource limitation that isn't present when you run the package manually.

Thanks,
Akhil.
Erland Sommarskog 137.4K Reputation points MVP Volunteer Moderator

2026-06-25T19:22:35.8866667+00:00

Thank you for the update. Since the package runs successfully under a sysadmin account but fails when executed by the SQL Agent service account,

Well, the service account for SQL Server Agent is a member of the sysadmin role in SQL Server. But this is obviously not a matter of SQL Server permissions, but permissions in Windows.

As for the issue as such, I don't have much to offer, since I don't know much about SSIS. But David Yard's post seems interesting.

Answer 1

Deepesh Dhake 1,165

Since the SSIS internal dump mechanism is bypassed, you may try following solutions:

Check Windows Event Viewer

Because the crash happened at the operating system level, Windows always logs it.

Open Event Viewer.
Expand Windows Logs then Application.
Look for an Error level event sourced from Application Error or .NET Runtime occurring at the exact second the job failed.
The error message will usually identify the exact faulting module.

Configure Windows Error Reporting (LocalDumps)

You can force the Windows operating system itself to catch the process crash and generate a dump file, circumventing SSIS entirely.

Open the Registry Editor (regedit) on the SQL Server machine.
Navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
Create a new key named ISServerExec.exe.
Inside that key, create a Expandable String Value (REG_EXPAND_SZ) named DumpFolder and set its value to a folder path (e.g., C:\CrashDumps).
Create a DWORD (32-bit) Value named DumpType and set it to 2 (this forces a Full Dump).
Run the failing job again. Windows will intercept the unhandled crash and drop a full .dmp file into that folder.

Review the SSISDB Catalog Reports

If the package ran for a short period before dying, some clues might have been flushed to the SSIS catalog database before the termination. Right-click your package in SQL Server Management Studio (SSMS), go to Reports then Standard Reports then All Executions, and click on All Messages for the failed run.

Peter Bishop 256 Reputation points

2026-06-16T19:20:29.3933333+00:00

Thanks for the feedback.

The Windows logs have recorded nothing, even if I select everything that occurred during the time window - all I see are some database backups.

The catalog messages record the Pre-Execute of the problematic Script Task and nothing more.

As this is a production system, I'm limited on the registry changes on the fly but I'll try and get that setup once I've been able to book it in.
Peter Bishop 256 Reputation points

2026-06-17T08:20:37.1766667+00:00

Have isolated this to a "permissions" issue, I think. I ran the package directly from the catalog using my login (part of sysadmin) without issue. I then ran it using the same account as the SQL Agent job step was using and it failed with an Unexpected Termination. If I limit the amount of data returned from SQL, it's fine. But beyond a certain (and inconsistent) point, it just dies.

I can run the package limited to 1000 rows, for example, and it works. Run it again immediately afterwards without changing anything and it'll fail.

Answer 2

This caught me off guard the first time too. The most common reason no dump file is created is that the target folder either does not exist or the SQL Server Agent service account does not have write access to it. Check that first before anything else.

The default dump location is:

C:\Program Files\Microsoft SQL Server\<instance>\Shared\ErrorDumps

Grant the Agent service account full write access to that folder. If the folder does not exist create it manually and then set the permissions.

You can also confirm where SQL Server is actually configured to write dumps:

sql

EXEC xp_instance_regread 
    N'HKEY_LOCAL_MACHINE',
    N'SOFTWARE\Microsoft\Microsoft SQL Server\<InstanceName>\CPE',
    N'SqlDumpDir';

The other thing worth knowing is that Dump on errors only fires on managed SSIS errors. If the package is terminating unexpectedly due to an out-of-memory condition, a process crash, or an external dependency failure, the dump mechanism is bypassed entirely and nothing gets written. Check the Windows Event Log at the exact time of failure. That will often tell you more than the SSIS logs in these cases.

Also make sure the target volume has available disk space. A full disk causes the dump to silently fail with no notification.