SDK Version
4.5
Unity Version
2022.3.62f2
Platform
Sentry Environment
Sentry SaaS (sentry.io)
Other Error Monitoring Solution
No
Steps to Reproduce
Native crash capture has never worked for us in a Windows build. Users report them by hand.
A Mono build ships two files named sentry.dll. The managed Sentry SDK lands in
Managed/, the real native library sits at the build root. Mono probes the calling
assembly's own folder first, and Sentry.Unity.Native lives in Managed/, so
DllImport("sentry") binds to the managed assembly and then dies looking for a C
function that isn't there.
That surfaces as EntryPointNotFoundException rather than DllNotFoundException.
The dll loads, it is just the wrong dll. Nothing else in our Sentry setup is wrong.
We never saw it because sentry-unity 2.4.0 stopped sending native init failures
as events and started logging them to a logger that is null unless Debug is on.
Renaming the dll fixes the issue.
SDK 4.9.0 has the same bug, the
experimental Windows backend ships the same filename to the same folder, Mono
dllmap is ignored, and preloading the native dll with LoadLibraryW does not stop
Mono opening the managed one.
Expected vs Actual Result
Expected: crash report
Result: no crash report
SDK Version
4.5
Unity Version
2022.3.62f2
Platform
Sentry Environment
Sentry SaaS (sentry.io)
Other Error Monitoring Solution
No
Steps to Reproduce
Native crash capture has never worked for us in a Windows build. Users report them by hand.
A Mono build ships two files named sentry.dll. The managed Sentry SDK lands in
Managed/, the real native library sits at the build root. Mono probes the calling
assembly's own folder first, and Sentry.Unity.Native lives in Managed/, so
DllImport("sentry") binds to the managed assembly and then dies looking for a C
function that isn't there.
That surfaces as EntryPointNotFoundException rather than DllNotFoundException.
The dll loads, it is just the wrong dll. Nothing else in our Sentry setup is wrong.
We never saw it because sentry-unity 2.4.0 stopped sending native init failures
as events and started logging them to a logger that is null unless Debug is on.
Renaming the dll fixes the issue.
SDK 4.9.0 has the same bug, the
experimental Windows backend ships the same filename to the same folder, Mono
dllmap is ignored, and preloading the native dll with LoadLibraryW does not stop
Mono opening the managed one.
Expected vs Actual Result
Expected: crash report
Result: no crash report