---
title: "Known Limitations"
description: "Learn more about the Unity SDK's known limitations. "
url: https://docs.sentry.io/platforms/unity/troubleshooting/known-limitations/
---

# Known Limitations | Sentry for Unity

## [File System Access Permissions](https://docs.sentry.io/platforms/unity/troubleshooting/known-limitations.md#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](https://docs.sentry.io/platforms/unity/troubleshooting/known-limitations.md#stack-traces)

### [Line Numbers Missing On Button Click Events](https://docs.sentry.io/platforms/unity/troubleshooting/known-limitations.md#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`](https://docs.sentry.io/platforms/unity/troubleshooting/known-limitations.md#line-numbers-missing-in-events-captured-through-debuglogerror-or-sentrysdkcapturemessage)

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`](https://docs.sentry.io/platforms/unity/troubleshooting/known-limitations.md#line-numbers-missing-in-events-captured-through-debuglogexception)

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`](https://docs.sentry.io/platforms/unity/troubleshooting/known-limitations.md#events-captured-through-debuglogexception-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](https://docs.sentry.io/platforms/unity/troubleshooting/known-limitations.md#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](https://docs.sentry.io/platforms/unity/troubleshooting/known-limitations.md#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`](https://docs.sentry.io/platforms/unity/troubleshooting/known-limitations.md#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:**

| Pattern                          | What it means                                                         | Example                                                                   |
| -------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| `YourClass+<>c`                  | Cached delegate class for simple lambdas                              | `YourClass+<>c in ThrowExceptionInLinq { <lambda> }`                      |
| `YourClass+<>c__DisplayClass#_#` | Display class for closures that capture local variables               | `YourClass+<>c__DisplayClass12_0 in ThrowExceptionInClosure { <lambda> }` |
| `<>n__0`, `<>n__1`               | Compiler-generated method names (may appear in detailed stack traces) | Method name suffix distinguishing multiple lambdas                        |
| `{ <lambda> }`                   | Indicates the frame is from a lambda expression                       | Shown in Sentry issue titles                                              |
| `MoveNext`                       | State machine method for async/await or iterator methods              | Common in async methods and Unity coroutines                              |

**Example:**

If your code contains:

```csharp
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:

```bash
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](https://docs.sentry.io/platforms/unity/troubleshooting/known-limitations.md#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](https://docs.sentry.io/platforms/unity/troubleshooting/known-limitations.md#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