Some outputs, such as the XEvent call stack action output the raw stack frame information and require a rebase to loaded module information in order to symbolize. The security feature for random address virtualization loads images at different addresses each time the image is loaded. This requires the module base address and the raw address in order to calculate the relative virtual address for symbolization.
XEvent Callstack Action - great when doing histogram bucketing but requires dm_os_loaded_modules or the module output from a stack capture in order to symbolize. The SqlCallStackResolver can do this work as well.
XEvent Callstack_Rva Action - Requires no additional capture to symbolize but is not as performant as the callstack action. Use for targeted debugging efforts and low production rate events (Latch timeout, deadlock, etc.)
RVA Call Stack RVA
Several of us have been adding callstack_rva capabilities, upgrading outputs, etc. For example, a latch timeout message includes the RVA callstack of the owner when available, the XEvent Callstack_RVA action is exposed, and so forth.
Currently we are testing use of the changes with telemetry workloads and are beginning to roll the changes out (coming to a SQL Server near you, including box releases) and is restricted to specific scenarios at the current time.
Arvind has/is upgrading the SqlCallStackResolver to accommodate the RVA format.
dbcc stackdump (...) is receiving the SKIP_DUMP with option.
SKIP_DUMP does all the other work that dbcc stackdump normally does to generate a txt file and filter the results based on the (...) information, skipping actual dump generation. Instead, the RVA stack are generated to the output locations as well as a result set to the client. Each frame contains enough information to identify the proper pdb and resolve the stack frame.
When available you can use dbcc stackdump (...) with SKIP_DUMP to capture call stack(s) without requiring a dump.