#Issue grouping and Titles

1 messages · Page 1 of 1 (latest)

sullen dune
#

I have been playing with Stack Trace Rules for the last 3 days in a native C++ application to not get issues group or titled RtlReportFatalFailure on windows
this is currently what I have

family:native package:**/DirectML*.dll category=system
family:native package:ntdll.dll category=system # Last ditch effort to try to get ndll.dll to not show up
family:native package:**/nv*.dll category=driver # NVIDIA Drivers
family:native package:**/ati*.dll category=driver # AMD/ATI Drivers
family:native package:**/amd*.dll category=driver # AMD/ATI Drivers
family:native package:**/ig*.dll category=driver # Intel Drivers
family:native package:**/Qt6*.dll category=ui
family:native package:**/platforms/** category=ui
family:native category:driver -app -group
family:native category:std -app -group
family:native category:system -app -group
family:native category:telemetry -app -group
family:native category:ui -app -group
family:native category:std -app -group

And this is having no effect I still get stack traces like this and issues get titled RtlReportFatalFailure and getting all kinds of weird grouping.
Hovering over the issue seams to show “Crashed in no app code” so I seams like it’s finding in app / out of app correctly. With stacktraces like this
sense I have no access to change ntdll.dll it really would be nice name of the issue was SomeMethod5 not RtlReportFatalFailure. What am I missing?

ntdll RtlReportFatalFailure
ntdll RtlReportCriticalFailure
ntdll RtlpHeapHandleError
ntdll RtlpHpHeapHandleError
ntdll RtlpLogHeapFailure
ntdll RtlFreeHeap
app.exe SomeMethod5
app.exe SomeMethod4
app.exe SomeMethod3
app.exe SomeMethod2
app.exe SomeMethod1
app.exe SomeMethod0

opaque lotus
#

The primary concern on Windows is typically that all frames are marked as System frames. These are identifiable visually when the module- and function-names are rendered in italic and no "In App" marker exists on the right side of each frame.

#

"In App" frames, besides having this marker would be rendered non-italic and in a slightly darker font-color.

#

in your stack-trace rules there are no positive in-app selectors (+app), so there is a good chance that none of your frames will be marked as "In App" even if the negative in-app markers (-app) correctly mark a module/package as outside the app package.

#

So, one of the first things I recommend is to positively mark a package/module (app.exe in your example) or namespace as "In App" (+app) right at the beginning of your stack rules. Often this is already enough (although it is certainly not a bad idea to explicitly mark some of the system dependencies).

#

As soon as there is an "In App" frame with a resolved symbol in your stack trace, it will be the top-most symbolicated "In App" frame(s) that contribute(s) to the name and grouping, all system frames above it will be ignored.

If there are no (symbolicated) in-app frames it will be the top-most (symbolicated) system frame(s) that contribute(s) to grouping, even if all the top-most frames are in your application.

This can lead to weird situations where frame-symbols at the beginning of the stack-trace provide the name for the event.

#

Also have a look at "Event Grouping Information" in your event view where you have hierarchical debugging view to see which rule helped which frame to contribute to the grouping. You can also compare it to all values that were evaluated for grouping contribution.