We are in the final stages of a structured evaluation of SentinelOne against our incumbent endpoint solution. The core test environment includes a mix of modern Windows 10/11 machines and a smaller, critical segment of Windows Server 2012 R2 systems running a legacy, vendor-abandoned line-of-business application. This application is a 32-bit process with known memory management idiosyncrasies.
Since deploying the S1 agent (Singularity Complete 23.4.2.3) to these legacy servers, we have experienced consistent, daily application crashes during high-volume batch processing periods. The crashes correlate precisely with S1 agent activity observed in the Windows Event Logs. Our incumbent AV (configured with a full exclusion for the app directory and process) had no such interaction.
Relevant log snippet from Application Event Log (Event ID 1000) is below. The faulting module is consistently `SentinelOneSvc.dll`.
```
Faulting application name: legacyLOB.exe, version: 5.2.1.1142, time stamp: 0x4a5bc411
Faulting module name: SentinelOneSvc.dll, version: 23.4.2.3, time stamp: 0x645a123b
Exception code: 0xc0000005
Fault offset: 0x000000000006a1fc
```
Our current mitigation steps, attempted sequentially with testing after each, have been unsuccessful:
* Created a full directory and process exclusion for the application within the S1 policy.
* Added the application's executable and its parent directory to the S1 Deep Visibility exclusion list.
* Attempted to disable the "Script-Based Injection" mitigation module specifically for this group of servers.
The crash persists. This suggests the interference is at a lower level than standard file scanning, possibly related to S1's memory inspection or behavioral AI drivers.
I am seeking analysis from others who have encountered similar conflicts between S1 and unsupported, legacy applications. Specifically:
* Has anyone successfully stabilized a similar scenario through more granular registry or kernel-level exclusions?
* Is there a documented method to configure S1 in a true "monitor-only" or passive mode on a per-device basis, where all mitigations are disabled but visibility remains?
* Are there known incompatibilities between S1's `SentinelOneSvc.dll` and older, multi-threaded 32-bit applications that perform custom memory allocation?
Our evaluation criteria heavily weights platform stability, and this is a significant blocker. We require a deterministic solution beyond "upgrade the legacy app," as that is not feasible within our timeline. Any detailed workflow reports or specific registry-based policy adjustments would be greatly appreciated.