Overview
The BugSplat .NET SDK supports applications written using the Microsoft Common Language Runtime (CLR).
This includes applications written using C#. The managed call stacks captured at the time of a crash
include function names, source code file names, and line numbers. In addition, BugSplat will also display
mixed-mode call stacks which have both managed code and native code on the stack.
To get started, make sure to log in using your
email address and download the BugSplat software
development kit for .NET Framework / C# applications.
To get a feel for the BugSplat service before enabling your application, feel free to experiment with
the myDotNetCrasher sample application, which is part of the BugSplat software development kit. You may
also want to browse the .NET API
documentation.
Instructions for modifying the default crash dialog can be found on the Windows Dialog Box page.
Enabling your application with BugSplat
technology:
In a few simple steps, your .NET application can be modified to provide full debug information on the
BugSplat website when it crashes.
- Add a reference to "BugSplatDotNet.dll".
-
Add a call to BugSplat.CrashReporter.Init and add the BugSplat exception handlers for the
appropriate
set of system exceptions.
As shown in the myDotNetCrasher sample app, this takes just a few lines of code.
-
The initialization call requires three parameters: BugSplat database, application name and
version. You supply the application name and version.
-
The BugSplat database is created on the Company page.
Typically, you will create a new database for each major release of your product.
-
Add
BsSndRpt.exe
, BugSplatDotNet.dll
, and BugSplatRC.dll
to
your application's installer.
-
Edit
BugSplatRC.dll
with Visual Studio if you wish to change the banner displayed when
your application crashes.
-
Add symbolic debug information to your release build.
-
Important! To get symbolic stack reports, debug information (pdb, dll and executable files) needs to be uploaded to the
BugSplat website along
with your application’s executable files.
Modify your build settings so that symbol files are created for Release builds, e.g.,
- Remember that after each build you should upload the new executable and files. The myDotNetCrasher sample app uses a Visual Studio post build
event to automate this step.
- Finally, note that the Visual Studio debugger's hosting process can interfere with BugSplat's
ability
to resolve symbols; it should be disabled in your project's debug settings when submitting crash
reports
that occur while debugging.
- Test your application by forcing a crash, and then verify that crashes are posted and symbol names
are
resolved.
-
You can verify symbols have been posted on the Symbols page.
-
You can view a list of crashes that have been posted to BugSplat on the Crashes page.