An app update goes out on Monday. By Wednesday, thirty people have each lost work once — and each one thinks the problem is their PC. Fleet-wide crash data shows the truth in one view.
Application crashes are where DEX earns its keep fastest. One user with a crashing app is a support ticket. The same app, same version, crashing on dozens of devices is a deployment problem — and only fleet-wide data can tell the two apart. DEX counts application crashes per device as the Application Reliability pillar and correlates them across models, OS versions and app versions, so the pattern surfaces as a single insight instead of a month of unrelated complaints.
👆 One version stands out from the fleet — that is the fix target (example figures)
Handled desk by desk, a bad version produces endless identical tickets: reinstall the app, clear the profile, blame the PC. Each fix "works" until the next crash, because the fault travels with the version, not the machine. Meanwhile the one PC still on the old version never crashes — the control sample nobody notices. Fleet correlation is what turns these scattered tickets into the single sentence that matters: version 6.2.1 is broken, roll it back or patch it.
Before rolling anything back, confirm the shape of the problem. Is it one version, or all versions on one device model, or one OS build? DEX's root-cause views group telemetry by device model, OS and application version precisely so you can separate a bad app release from a bad driver on one laptop family. Also check the timeline: crashes that begin the morning after a deployment are a confession, not a coincidence.
Fleet patterns are satisfying, but most crash lists are a long tail of one PC crashing for its own reasons — failing RAM, a corrupt profile, a dying disk corrupting the app's data. The same DEX view separates these: a device whose crashes span many different apps is usually a hardware suspect, not a software one. Send those down the hardware diagnosis path instead of reinstalling applications on a machine whose memory is quietly failing.
After the rollback or patch, the crash insight should decay to near zero within days. If it halves instead, you fixed one of two causes. Keep the insight open until the number, not the effort, says done. Over a quarter, these records become your evidence in vendor conversations — "your 6.2.1 crashed 612 times on our fleet in a week" ends arguments that opinions never will.
The video walks through crash insights on a live console — watch how fast a fleet pattern appears once the data is in one place.
▶️ Watch Full VideoGroup the crashes. If they concentrate on one application version across many different devices and started right after that version deployed, the version is the suspect. If they concentrate on one device across many applications, the device is the suspect.
It depends on crash frequency and the vendor's confirmed timeline. Daily crashes destroying work argue for rollback now. Rare crashes with a hotfix promised in days can justify holding — but pause further rollout either way.
Per ManageEngine's documentation, crash events are recorded immediately when they occur, while periodic metrics like CPU are sampled at intervals. Scores are then computed daily from the collected data.