IronPDF on Windows: Sophos DynamicShellcode / HeapHeapHooray Detection (.NET Framework)

Overview

Sophos exploit mitigation can flag IronPDF’s native DLL load path in .NET Framework applications because the LoadLibrary call for IronInterop.dll originates from CLR JIT-compiled memory. This can block application startup even when the IronPDF binaries are official, signed, and unmodified. The practical fix is to use a narrowly scoped Sophos exclusion or move PDF processing to IronPdfEngine in gRPC remote mode.

Environment

• OS: Windows 10 x64

• Affected Versions: IronPDF 2026.3.1

• Language/Runtime: .NET Framework

Version Metadata

• Version Found: 2026.3.1
• Version Resolved: N/A

Cause

Sophos DynamicShellcode / HeapHeapHooray uses behavioral exploit-mitigation heuristics. In this case, it detects the native DLL load path used by IronPDF in a .NET Framework process and blocks startup because the load request appears to come from anonymous CLR-managed memory rather than a file-backed origin.

Solution

1. Recommended: Add the narrowest Sophos exclusion available for this detection. Prefer a certificate-based allow rule for Iron Software signed binaries or an exclusion for the specific Sophos detection ID confirmed by Sophos Support.

2. If endpoint exclusions are not acceptable, run IronPDF through IronPdfEngine in gRPC remote mode, so the native loading happens in a separate process instead of inside the .NET Framework client application.

3. Keep the exclusion scope narrow. Do not disable DynamicShellcode protection broadly for the whole application unless Sophos provides no narrower option and the customer’s security team approves it.

4. If you need exact exclusion details, verify the final rule format with the customer’s Sophos administrator or Sophos Support.