Multiple statically linked sentry-native instances in different DLLs within the same Windows process

[xbommel12345-droid]

Hi,

We have several Windows DLLs that are loaded into the same Windows process. We do not have access to or control over the host process.

Our setup is:

Multiple DLLs are loaded into the same Windows process.
Each DLL statically links its own copy of sentry.lib and crashpad.lib.
Each DLL uses a different Sentry DSN / Project ID.
Each DLL independently calls sentry_init().
The host process itself does not initialize Sentry and cannot be modified.
We use the Crashpad backend.

For example:

HostProcess.exe
├── PluginA.dll
│ ├── sentry.lib → Project A
│ └── crashpad.lib
├── PluginB.dll
│ ├── sentry.lib → Project B
│ └── crashpad.lib
└── PluginC.dll
├── sentry.lib → Project C
└── crashpad.lib

We have tested this setup with all three DLLs. When deliberately crashing inside each DLL, the crash has consistently been reported to the corresponding Sentry project.

Our question is:

Is this architecture officially supported by sentry-native?

More specifically:

Is it supported to have multiple independent statically linked instances of sentry-native in the same Windows process?
Is it supported for each instance to initialize its own Crashpad handler?
Is the behavior of routing a crash to the Sentry instance / DSN associated with the crashing DLL guaranteed?
Are there known limitations or race conditions when multiple sentry_init() calls occur from different DLLs in the same process?
Does the answer differ depending on whether crashpad, breakpad, native, or inproc is used as the backend?
Is there any global Windows/WER/Crashpad state that makes multiple independent instances unsafe?

We are particularly interested in whether this is a supported architecture rather than merely behavior that happens to work in our current tests.

We are using Windows with MSVC and the Crashpad backend.

Thank you in advance!

-Kai

[jpnurmi]

The problem is that crash handling in general is process-wide. Although each statically linked sentry-native instance has its own options, the DLL containing the faulting instruction does not determine which instance handles the crash.

The reported "working" behavior can occur coincidentally. For example, with a static MSVC runtime (/MT), each DLL has separate CRT signal state. An abort() inside a DLL can invoke that DLL's locally registered SIGABRT handler and use its sentry-native instance, which could explain the behavior you're seeing. In contrast, a regular access violation may be handled by the last initialized instance, regardless of where it occurred. The same applies to abort() with the shared runtime (/MD).

Initialization order, crash type, reinitialization, and DLL unloading can all affect the result. For predictable behavior, one component should own a process-wide sentry-native instance.