Corrupted display when exception data is set using native sdk

This issue can be seen at (login required I presume).

Using the native sdk, everything works well with call stacks etc, until we add the exception context. As soon as we set exception data, the stack trace for the event is corrupted, as shown in the screenshot below.

You can see how under the STACKTRACE header, the normal stack trace is not shown (I can only include a single image in this post otherwise I’d give an example of what I see normally).

The way we generated this event was, roughly (this is simplified slightly to use constant strings):

  event = sentry_value_new_event();
  exc = sentry_value_new_object();
  sentry_value_set_by_key(exc, "type", sentry_value_new_string("Exception"));
  sentry_value_set_by_key(exc, "value", sentry_value_new_string("Crash"));
  sentry_value_set_by_key(event, "exception", exc); // if we comment this out, the stack trace appears correctly.
  sentry_event_value_add_stacktrace(event, NULL, 64);

What are we missing in the exception data in order to get it to display the stack trace correctly on (Symbolication etc is all working fine; this is a minimal test to try and trace the issue)

Note: the raw stack trace data is shown as follows:

OS Version: None None (None)
Report Version: 104

Application Specific Information:
Exception Exception in module SentryClientTest.exe at 0001CE7D. This should be captured by TSentryClient. 

Thread 0
0   <unknown>                       0x595ac033          <unknown>
1   <unknown>                       0x10896459          <unknown>
2   <unknown>                       0x4ce91beb          <unknown>
3   <unknown>                       0x1fffe9b           <unknown>
4   <unknown>                       0x10000000          <unknown>
5   <unknown>                       0xffffffff98004138L <unknown>
6   <unknown>                       0xffffffffe80041ceL <unknown>
7   <unknown>                       0xfffffffffffff683L <unknown>
8   <unknown>                       0xfffffffffe9e62e8L <unknown>
9   <unknown>                       0x5ac033ff          <unknown>
10  <unknown>                       0xffffffff89645959L <unknown>
11  <unknown>                       0xffffffffcebf6810L <unknown>
12  <unknown>                       0x458b0041          <unknown>
13  <unknown>                       0xffffffff88a5e8fcL <unknown>
14  <unknown>                       0xffffffffe9c3fffeL <unknown>
15  <unknown>                       0xfffffffffffe9ca3L <unknown>
16  <unknown>                       0x5e5ff0eb          <unknown>
17  <unknown>                       0xffffffffc35d595bL <unknown>
18  <unknown>                       0xffffffffb0000000L <unknown>
19  <unknown>                       0xffffffffff000204L <unknown>
20  <unknown>                       0x28ffffff          <unknown>
21  <unknown>                       0x54000000          <unknown>
22  <unknown>                       0x69006800          <unknown>
23  <unknown>                       0x20007300          <unknown>
24  <unknown>                       0x68007300          <unknown>
25  KERNELBASE.dll                  0x75006f00          <unknown>
26  <unknown>                       0x64006c00          <unknown>
27  <unknown>                       0x62002000          <unknown>
28  <unknown>                       0x20006500          <unknown>
29  <unknown>                       0x61006300          <unknown>
30  <unknown>                       0x74007000          <unknown>
31  <unknown>                       0x72007500          <unknown>
32  <unknown>                       0x64006500          <unknown>
33  <unknown>                       0x62002000          <unknown>
34  <unknown>                       0x20007900          <unknown>
35  <unknown>                       0x53005400          <unknown>
36  <unknown>                       0x6e006500          <unknown>
37  <unknown>                       0x72007400          <unknown>
38  <unknown>                       0x43007900          <unknown>
39  <unknown>                       0x69006c00          <unknown>
40  <unknown>                       0x6e006500          <unknown>
41  <unknown>                       0x7400              <unknown>
42  <unknown>                       0x55000000          <unknown>
43  <unknown>                       0xffffffffc483ec8bL <unknown>
44  <unknown>                       0xfffffffffccde8ecL <unknown>
45  <unknown>                       0x4589ffff          <unknown>
46  <unknown>                       0x55c033fc          <unknown>
47  <unknown>                       0x41cf7468          <unknown>
48  <unknown>                       0x30ff6400          <unknown>
49  <unknown>                       0x68208964          <unknown>
50  SentryClientTest.exe            0x41cf8c            SentryClientTestSentryclienttestmainmain$qqrv
51  <unknown>                       0x458d016a          <unknown>
52  <unknown>                       0xffffffffd8b950ecL <unknown>
53  <unknown>                       0x330041cf          <unknown>
54  <unknown>                       0xfffffffffc458bd2L <unknown>
55  <unknown>                       0xfffffffffffb72e8L <unknown>
56  <unknown>                       0x5ac033ff          <unknown>
57  <unknown>                       0xffffffff89645959L <unknown>
58  <unknown>                       0xffffffffcf7b6810L <unknown>
59  <unknown>                       0x458b0041          <unknown>
60  <unknown>                       0xffffffff87e9e8fcL <unknown>
61  <unknown>                       0xffffffffe9c3fffeL <unknown>
62  <unknown>                       0xfffffffffffe9be7L <unknown>
63  <unknown>                       0xffffffffe58bf0ebL <unknown>

Anyone? I’ve replicated this on as well:

I would try upgrading the SDK first and if that doesn’t help, report the bug at

Updated to 0.2.3 and same result. Reported at