OLD | NEW |
(Empty) | |
| 1 # Windows Integration overview |
| 2 |
| 3 ## Windows Client Code |
| 4 |
| 5 The Windows client code is in the `src/client/windows` directory of the tree. |
| 6 Since the header files are fairly well commented some specifics are purposely |
| 7 omitted from this document. |
| 8 |
| 9 ## Integration of minidump-generation |
| 10 |
| 11 Once you build the solution inside `src/client/windows`, an output file of |
| 12 `exception_handler.lib` will be generated. You can either check this into your |
| 13 project's directory or build directly from the source, as the project itself |
| 14 does. |
| 15 |
| 16 Enabling Breakpad in your application requires you to `#include |
| 17 "exception_handler.h"` and instantiate the `ExceptionHandler` object like so: |
| 18 |
| 19 ``` |
| 20 handler = new ExceptionHandler(const wstring& dump_path, |
| 21 FilterCallback fil
ter, |
| 22 MinidumpCallback c
allback, |
| 23 void* callback_con
text, |
| 24 int handler_types, |
| 25 MINIDUMP_TYPE dump
_type, |
| 26 const wchar_t* pip
e_name, |
| 27 const CustomClient
Info* custom_info); |
| 28 ``` |
| 29 |
| 30 The parameters, in order, are: |
| 31 |
| 32 * pathname for minidumps to be written to - this is ignored if OOP dump |
| 33 generation is used |
| 34 * A callback that is called when the exception is first handled - you can |
| 35 return true/false here to continue/stop exception processing |
| 36 * A callback that is called after minidumps have been written |
| 37 * Context for the callbacks |
| 38 * Which exceptions to handle - see `HandlerType` enumeration in |
| 39 exception\_handler.h |
| 40 * The type of minidump to generate, using the `MINIDUMP_TYPE` definitions in |
| 41 `DbgHelp.h` |
| 42 * A pipe name that can be used to communicate with a crash generation server |
| 43 * A pointer to a CustomClientInfo class that can be used to send custom data |
| 44 along with the minidump when using OOP generation |
| 45 |
| 46 You can also see `src/client/windows/tests/crash_generation_app/*` for a sample |
| 47 app that uses OOP generation. |
| 48 |
| 49 ## OOP Minidump Generation |
| 50 |
| 51 For out of process minidump generation, more work is needed. If you look inside |
| 52 `src/client/windows/crash_generation`, you will see a file called |
| 53 `crash_generation_server.h`. This file is the interface for a crash generation |
| 54 server, which must be instantiated with the same pipe name that is passed to the |
| 55 client above. The logistics of running a separate process that instantiates the |
| 56 crash generation server is left up to you, however. |
| 57 |
| 58 ## Build process specifics(symbol generation, upload) |
| 59 |
| 60 The symbol creation step is talked about in the general overview doc, since it |
| 61 doesn't vary much by platform. You'll need to make sure that the symbols are |
| 62 available wherever minidumps are uploaded to for processing. |
| 63 |
| 64 ## Out in the field - uploading the minidump |
| 65 |
| 66 Inside `src/client/windows/sender` is a class implementation called |
| 67 `CrashReportSender`. This class can be compiled into a separate standalone CLI |
| 68 or in the crash generation server and used to upload the report; it can know |
| 69 when to do so via one of the callbacks provided by the `CrashGenerationServer` |
| 70 or the `ExceptionHandler` object for in-process generation. |
OLD | NEW |