The current msvc-based stacktrace only determines the module name - not its complete path - contrary to the full featured unixoid implementation. It turns out that this is rather simple to realize and valuable when attempting to analyze application problems by inspecting the referred to image paths. It means that you first calls IDebugSymbols::GetModuleByOffset followed by IDebugSymbols::GetModuleNames using the ImageNameBuffer, ImageNameBufferSize, and ImageNameSize parameters. I'm using this extended information in my own stacktrace implementation.
There is another way of improving the quality of msvc stacktraces related to the problem described capturestackbacktrace-randomly-fails-after-initial. I'm aware that the current stacktrace implementation has eliminated any explicit call of CoInitializeEx, but that does not prevent the user to make such a call. Instead of rewriting RtlCaptureStackBackTrace as suggested in this article, a very simple workaround seems to help here. Before calling RtlCaptureStackBackTrace with a static buffer (128), just call RtlCaptureStackBackTrace with the FramesToCapture equal to just 1 ignoring this stub call, which prevents the potential empty stacktrace situation for the second call.
Would there be interest for a corresponding PULL request?
The current msvc-based stacktrace only determines the module name - not its complete path - contrary to the full featured unixoid implementation. It turns out that this is rather simple to realize and valuable when attempting to analyze application problems by inspecting the referred to image paths. It means that you first calls IDebugSymbols::GetModuleByOffset followed by IDebugSymbols::GetModuleNames using the
ImageNameBuffer,ImageNameBufferSize, andImageNameSizeparameters. I'm using this extended information in my own stacktrace implementation.There is another way of improving the quality of msvc stacktraces related to the problem described capturestackbacktrace-randomly-fails-after-initial. I'm aware that the current stacktrace implementation has eliminated any explicit call of
CoInitializeEx, but that does not prevent the user to make such a call. Instead of rewritingRtlCaptureStackBackTraceas suggested in this article, a very simple workaround seems to help here. Before callingRtlCaptureStackBackTracewith a static buffer (128), just callRtlCaptureStackBackTracewith theFramesToCaptureequal to just1ignoring this stub call, which prevents the potential empty stacktrace situation for the second call.Would there be interest for a corresponding PULL request?