Problem Statement

Native crashes are invisible to executable-name searches when the
faulting frame isn't owned by the binary in question.

Today, the only way to find crashes associated with a specific
executable is stack.package:*foo.exe*, which only matches when
foo.exe owns at least one frame in the crash stack. If foo.exe
loads a DLL that faults on its own worker thread, no foo frames
appear on the crashing stack — and the event becomes unfindable in
Issues/Discover, even though Sentry already stores foo.exe in the
event's debug_meta.images[].code_file as a loaded module.

Concrete customer scenario: they ship iwproxygen.exe, which loads
a DLL that runs on its own threads and occasionally faults. They
need to surface every crash where iwproxygen.exe was loaded into
the process — regardless of which binary owns the faulting frame —
and currently cannot.

Related: #83608 (same underlying ask).

Solution Brainstorm

Expose the basename of each loaded image from
debug_meta.images[].code_file (just the filename + extension, not
the full path) as a searchable tag/field in Issues and Discover.

Suggested field name: code_filename. Usage:

code_filename:iwproxygen.exe

Basename rather than full path because:

• Low cardinality — full paths vary by machine, install dir, drive
  letter, and locale; basenames don't
• Plays nicely with search autocomplete
• Mirrors how stack.package already behaves on native in spirit

The data is already stored on every native event — this should be
purely an indexing/exposure change on the platform side, no SDK
work required.

Product Area

Issues