VediramCrash Analysis
Understand and investigate Office crashes attributed to add-ins
Overview
The Crashes page shows Office crashes that Deck attributes to add-ins. Deck runs a three-tier analysis pipeline, using the deepest tier the available data allows, so each report carries as much detail as possible.
How crash detection works
| Tier | Source | What it extracts |
|---|---|---|
| Tier 0 | Windows Event Log, Office crash-recovery keys, and Windows Error Reporting entries | The crash event, the Office app, and timing - with no extra dependencies |
| Tier 1 | Minidump (.dmp) files | The list of loaded modules to identify the faulting DLL |
| Tier 2 | Managed (.NET) analysis of the dump | Stack traces and the specific VSTO/managed add-in involved |
Deck monitors the crash-dump folder - by default %LOCALAPPDATA%\CrashDumps - for new dumps. Administrators can redirect this with the CrashDumpsFolder policy.
Viewing crash reports
Each report shows:
- Date and time of the crash
- Office application that crashed
- Faulting module - the DLL or add-in identified as the likely cause
- Analysis tier used, and the confidence of the attribution
- Stack trace, when Tier 2 analysis was possible
Retention
Crash reports are kept for 30 days; older reports are pruned automatically when the daemon starts. Export or submit anything you need to keep before it ages out.
What to do with crash data
If an add-in appears repeatedly:
- Check whether an update is available for it.
- Create a profile that disables it.
- Submit a support request with the crash details for further investigation.
If the Crashes page is missing
Crash analysis can be turned off by IT with the DisableCrashAnalysis policy; when it is, the Crashes page doesn't appear and the page shows a managed by IT indicator. Administrators: see the Policy Reference.