Known Limitations

File System Access Permissions

Starting with macOS Mojave (10.14), directories like Desktop, Documents, and Downloads are considered privacy-sensitive locations and are protected by the operating system's security sandbox. When running a Unity application from one of these locations, users might encounter a popup requesting access. This occurs because the default .NET HttpMessageHandler attempts to resolve domain names, which requires filesystem access. Note, that disallowing access to these locations does not affect the SDK from reporting errors.

Stack Traces

Line Numbers Missing On Button Click Events

Currently, line numbers are missing when programmatically subscribing to button click events via Button.onClick.AddListener. However, you can set up callbacks through the editor to work around this.

Line Numbers Missing in Events Captured Through Debug.LogError or SentrySdk.CaptureMessage

The SDK is currently limited to resolving IL2CPP line numbers when capturing errors. The SDK relies on an exception being available to extract the stacktrace. That means that either an unhandled exception needs to be caught by the SDK automatically or by calling SentrySdk.CaptureException manually.

When logging an error with Debug.LogError the logging integration captures this as message.

Line Numbers Missing in Events Captured Through Debug.LogException

The exception provided by Unity that is getting captured by the logging integration does not contain a stacktrace. Use SentrySdk.CaptureException instead.

Events Captured Through Debug.LogException Are Marked as Unhandled

Currently, it is not possible for the SDK to distinguish between the user calling Debug.LogException and the SDK capturing an unhandled exception. To capture an exception and mark it as handled you can call SentrySDK.CaptureException instead.

Line Numbers Missing when Building with Mono

When building with Mono, make sure to set the ManagedStrippingLevel to None. Otherwise, Unity will strip the debug information from the assembly, which will cause the SDK to fail to retrieve the debug ID that allows connecting the assembly to the correct debug symbols for symbolication.

C++ as Part of the Stack Trace

Your stack traces might contain C++ frames. This might be because:

• The generated C++ code doesn't contain the <source_info> annotation to point back to the C# code it was generated from. This can be due to optimization or the IL2CPP compiler generating code to handle C# specific features.
• The C++ exception might return an incorrect line number which makes Sentry miss the <source_info> annotation. You can try enabling uploading your source code in the debug symbol options to look at the generated C++ code.

This is also why you might end up with very high line numbers (in the several thousands) even though your C# script is very small; the line numbers relate to the generated C++ code.

Stack traces contain frames with <>n__0, <>c, or <>c__DisplayClass

When viewing stack traces in Sentry, you may encounter compiler-generated class and method names with patterns like <>c, <>c__DisplayClass#_#, <>n__0, or { <lambda> }. These are created by the C# compiler when you use:

• Lambda expressions: Anonymous functions like items.Where(x => x.IsActive)
• Delegates: Inline delegate definitions such as Action, Func
• LINQ expressions: Query syntax and method chains
• Async/await: State machine methods for asynchronous operations (may show MoveNext)
• Iterator methods: Coroutines and methods using yield return (may show MoveNext)
• Event handlers: Lambda expressions in event subscriptions
• UI callbacks: Unity button click handlers like button.onClick.AddListener(() => {...})

Common patterns you'll see:

Example:

If your code contains:

public void ThrowExceptionInLinq()
{
    var numbers = new List<int> { 1, 2, 3, 4, 5 };
    var result = numbers.Where(n =>
    {
        if (n == 3) throw new InvalidOperationException("Error!");
        return n > 2;
    }).ToList();
}

The Sentry issue will show something like:

YourClass+<>c in ThrowExceptionInLinq { <lambda> }

How to interpret these frames:

1. +<>c: The + indicates a nested class. <>c is a cached delegate class that holds the lambda's compiled code
2. +<>c__DisplayClass#_#: Similar to <>c, but used when the lambda captures local variables (creates a "closure")
3. Method name shown: Look at the parent method name (after "in") to identify where in your code the lambda was defined
4. { <lambda> }: Confirms the exception occurred inside the lambda expression itself
5. MoveNext: For async methods and coroutines, this is the state machine method that executes your code

These frames are normal and expected in C# applications. They provide precise information about where an exception occurred within lambda expressions and compiler-generated code.

Cysharp

Note: This issue is obsolete and resolved for Unity 2021+ with UniTask 2.5.10+

In older versions, the SDK failed to provide line numbers and source context in combination with Cysharp. This is because the SDK depends on Unity’s IL2CPP backend to supply instruction addresses, which Sentry uses to generate line numbers in events. However, when the stack trace entered the Cysharp library, those instruction addresses defaulted to 0x0, preventing line numbers from being reported.

This issue has been resolved in newer versions. If you're experiencing this problem, updating to Unity 2021 or later with UniTask 2.5.10 or later should resolve it.

WebGL Support

When targeting WebGL, you have the option of setting the PlayerSettings.WebGL.exceptionSupport, but be mindful of the following limitations:

• Setting it to WebGLExceptionSupport.None is not supported by the SDK.
• For the SDK to be able provide stack traces, the support needs to be set to WebGLExceptionSupport.FullWithStacktrace.
• The SDK is currently not able to provide line numbers due to the IL2CPP backend not being available.
• Native crash detection is not available on WebGL. The SDK cannot determine if the browser or tab crashed, which affects session tracking:
  • Sessions with captured exceptions are marked as Unhandled
  • Sessions where the tab/browser closes without a clean shutdown are marked as Abnormal
  • The Crash Free Session Rate will show 100% since native Crashed status is unavailable
  • Monitor both Unhandled and Abnormal session rates to track stability issues