SSIS Dumps and Runtime
Overview
Two columns every execution carries and no report reads.
dump_id
catalog.executions.dump_id names a memory dump file sitting on the SSIS host.
Nobody monitors that directory, the files are hundreds of megabytes each, and the first anyone hears of them is when the disk fills.
use32bitruntime
catalog.executions.use32bitruntime says the package ran under the 32-bit runtime.
A package forced to 32-bit is almost always reaching a Jet or ACE provider for Excel or Access, or an old Oracle client. It works today. It is the thing that stops the SQL Server upgrade, and it gets discovered during the upgrade window rather than before it.
Where to find it
Expand a server in the tree, expand a database holding an Integration Services catalog, then SSIS → Dumps and Runtime.
Why the two are on one page
Both mean the same thing to a reader: go and look at something outside the database.
A dump is a file this product cannot open, and a driver dependency is not in SQL Server at all, so the page says where to look rather than pretending it can follow.
One honesty the page needs
A dump is not always a crash.
DUMP_ON_ERROR and the dump-on-event settings produce them deliberately, so the catalog properties are read before anything is called a fault.
SSIS Overrides is where a DUMP_ON_ERROR set for one run shows up.
The two views
Memory dumps
| Column | What it is |
|---|---|
| When | When the execution ran. |
| Package / Project | What produced it. |
| Dump id | The dump_id, which is the file name on the host. |
| Status | How the run ended. |
| Host | machine_name: which machine the file is on. |
| Started by | The caller. |
| Execution | The execution_id. |
32-bit runtime
| Column | What it is |
|---|---|
| Package / Project | The package. |
| 32-bit runs | How many of its runs used the 32-bit runtime. |
| 64-bit runs | How many did not. A package with both is one somebody has been switching. |
| Last run | The most recent execution. |
| What it means | Why this package is probably pinned to 32-bit, and what that blocks. |
The toolbar
| Control | Options |
|---|---|
| View | Memory dumps, 32-bit runtime |
| Where to look | The dump directory path on the host, and what to do with the files. |
| Failures | Opens SSIS Package Failures. |
Where the data comes from
| Source | What it gives |
|---|---|
catalog.executions |
dump_id, use32bitruntime, machine_name, status, caller and timing. |
catalog.catalog_properties |
The dump-on-error and dump-on-event settings, read before a dump is called a fault. |
catalog.execution_parameter_values |
A DUMP_ON_ERROR set for one run. |
Related reports
| Report | Why you would go there |
|---|---|
| SSIS Package Failures | What the run that produced the dump actually said. |
| SSIS Overrides | Where DUMP_ON_ERROR was turned on for one run. |
| SSIS Schedule | Which host these runs are on. |
| SSIS Catalog Health | The other thing quietly filling disks. |
| Failover Compatibility | The upgrade question the 32-bit finding belongs to. |
Frequently asked questions
Where are the dump files? On the machine in the Host column, in the SSIS dump directory under the SQL Server instance’s Log folder. The Where to look button gives the path. This product cannot open them.
Is a dump always bad? No. DUMP_ON_ERROR produces one deliberately. The page reads the catalog properties before calling anything a fault.
We are upgrading SQL Server. Why does this page matter? Because a package pinned to the 32-bit runtime is reaching a 32-bit provider, and that provider is what will not be there afterwards. Finding it now costs an afternoon; finding it during the upgrade window costs the window.
A package shows both 32-bit and 64-bit runs. Somebody has been switching it, probably per run through an override. SSIS Overrides shows who and when.