Problem Statement
Native crash reports include the full list of loaded modules: DLLs, drivers,
injected overlays, graphics runtimes. This data is captured and displayed on the
event, but it is not searchable. There is no way to ask "show me every crash where
overlay X was loaded" or "every crash on graphics driver version Y".
For desktop and console applications, third-party injected modules are one of the
largest single causes of crashes that look like application bugs but are not.
Overlays, capture tools, anti-cheat layers, and out-of-date graphics drivers all
present as crashes inside the application's own stack.
Because the module list cannot be filtered on:
- Every one of these is triaged by hand.
- Teams cannot quantify how much of their crash volume is attributable to a given
third-party module, so they cannot prioritise it and cannot prove to the third
party that its module is the cause.
- The only workaround is exporting events and grepping the module list offline.
The data already exists on every native event. It is simply not indexed.
Solution Brainstorm
- Index the loaded-modules list as a searchable, multi-value attribute, including
module name and version.
- Support it in issue search, in Explore, and in dashboard group-bys, so a team can
chart crash volume by loaded module over time.
- Surface a loaded-module breakdown on the issue page, in the same spirit as the
existing tag distribution, so the correlation is visible without a query.
Product Area
Issues
Requested by Saad Khan.
--
View Junior Session [Sentry]
Problem Statement
Native crash reports include the full list of loaded modules: DLLs, drivers,
injected overlays, graphics runtimes. This data is captured and displayed on the
event, but it is not searchable. There is no way to ask "show me every crash where
overlay X was loaded" or "every crash on graphics driver version Y".
For desktop and console applications, third-party injected modules are one of the
largest single causes of crashes that look like application bugs but are not.
Overlays, capture tools, anti-cheat layers, and out-of-date graphics drivers all
present as crashes inside the application's own stack.
Because the module list cannot be filtered on:
third-party module, so they cannot prioritise it and cannot prove to the third
party that its module is the cause.
The data already exists on every native event. It is simply not indexed.
Solution Brainstorm
module name and version.
chart crash volume by loaded module over time.
existing tag distribution, so the correlation is visible without a query.
Product Area
Issues
Requested by Saad Khan.
--
View Junior Session [Sentry]