Extracting the stack trace is different from resolving the stack trace function pointers with symbols. For the extraction part, we read from dump files from external sources. For the resolution part, we read symbols from mostly internal sources unless otherwise provided. The latter can happen offline. There is support via debugger interface access sdk (DIA) and somewhat more generally with the debugger client sdk that gets shipped with debugging tools from windows. The latter has an interface in C# as opposed to the COM based interface of DIA. There is also more debugging features available via the debugging sdk.
The debugging sdk assembly (mdbgeng) requires full trust. When redistributing a package with this assembly, it's probably better to register it to the global assembly cache or use with NuGet. For the most part, we want to focus on preliminary analysis of dumps using streams.
Also we could provide APIs for the functionalities we write, so that any client, powershell or standalone executable can call these.
API design could consider a subset of the debugger sdk as appropriate. The two main methods we are interested in are GetStackTraceFromStream and OutputStackTrace.
The APIs could additionally consider methods for retrieving bucket information, timestamps, and additional details such as the system information on which the dump occurred.
The powershell implementation of these APIs are enabled via appropriate attribute on the methods mentioned above.
Exception handling and return values are limited to very few meaningful messages.
Also, deployment of a standalone tool for this can be MSI based so that install and uninstall is easy. The MSI can be generated with libraries such as WixSharp.
Next blog post will continue on text indexing methods.
The debugging sdk assembly (mdbgeng) requires full trust. When redistributing a package with this assembly, it's probably better to register it to the global assembly cache or use with NuGet. For the most part, we want to focus on preliminary analysis of dumps using streams.
Also we could provide APIs for the functionalities we write, so that any client, powershell or standalone executable can call these.
API design could consider a subset of the debugger sdk as appropriate. The two main methods we are interested in are GetStackTraceFromStream and OutputStackTrace.
The APIs could additionally consider methods for retrieving bucket information, timestamps, and additional details such as the system information on which the dump occurred.
The powershell implementation of these APIs are enabled via appropriate attribute on the methods mentioned above.
Exception handling and return values are limited to very few meaningful messages.
Also, deployment of a standalone tool for this can be MSI based so that install and uninstall is easy. The MSI can be generated with libraries such as WixSharp.
Next blog post will continue on text indexing methods.
No comments:
Post a Comment