[Bug] STS2-RitsuLib is blocked by Windows 11

[Lingygao]

模块范围

Public API（公开 API）

严重程度

Broken feature（功能不可用）

发生了什么？

加载 STS2-RitsuLib 时，模组加载器出现以下错误：

System.IO.FileLoadException: Could not load file or assembly
'...\Steam\steamapps\workshop\content\2868840\3747602295\STS2-RitsuLib.dll'.

应用程序控制策略已阻止此文件。 (0x800711C7)

Windows 的“代码完整性”日志中还记录了事件 ID 3077：

Code Integrity determined that SlayTheSpire2.exe attempted to load
STS2-RitsuLib.dll, but the DLL did not meet the Enterprise signing level
requirements or violated code integrity policy.

Policy ID: {0283ac0f-fff1-49ae-ada1-8a933130cad6}

运行环境：

Windows 11
已开启“智能应用控制”
使用 Steam 创意工坊版本的 STS2-RitsuLib
创意工坊项目 ID：3747602295

我已经尝试取消订阅并重新下载模组，但问题仍然存在。该 DLL 的文件属性中也没有“解除锁定”选项。请问这是已知问题吗？后续可以兼容 Windows 智能应用控制的版本吗？

复现步骤

1.通过 Steam 创意工坊订阅并安装 STS2-RitsuLib。
2.启动《杀戮尖塔 2》并进入模组加载流程。
3.右下角显示加载0个模组出现错误。
4.日志显示
System.IO.FileLoadException:
Could not load file or assembly
'...\Steam\steamapps\workshop\content\2868840\3747602295\STS2-RitsuLib.dll'.
应用程序控制策略已阻止此文件。 (0x800711C7)
5. 打开 Windows“事件查看器”，
可以看到对应的事件 ID 3077，提示
Id : 3077
Message : Code Integrity determined that a process (\Device\HarddiskVolume3\Program Files (x86)\Steam\steamapps\com
mon\Slay the Spire 2\SlayTheSpire2.exe) attempted to load \Device\HarddiskVolume3\Program Files (x86)\Ste
am\steamapps\workshop\content\2868840\3747602295\STS2-RitsuLib.dll that did not meet the Enterprise signi
ng level requirements or violated code integrity policy (Policy ID:{0283ac0f-fff1-49ae-ada1-8a933130cad6}
).

期望行为

No response

日志 / 堆栈

RitsuLib 版本

No response

运行环境

No response

[ritsukage-local-analyzer]

Warning

此分析由 AI 自动生成，仅供开发者参考，最终判断请以人工确认为准。如有疑问建议结合本地环境进一步复现确认。

摘要

该问题表现为 Windows 11「智能应用控制」/ 代码完整性策略在加载 Steam 创意工坊版 STS2-RitsuLib.dll 时直接拦截 DLL，错误码为 0x800711C7。这会让启用该策略的用户完全无法加载 RitsuLib，但目前更像是发布包信任/签名链问题，而不是公开 API 运行逻辑缺陷。

建议维护者优先确认创意工坊发布产物是否具备 Windows 可接受的 Authenticode 签名，必要时调整发布/Workshop 流程；同时请报告者补充精确版本与完整模组加载器日志以确认影响范围。

重点结论

项目	结论
简单介绍	启用 Windows 11 智能应用控制后，游戏进程尝试加载 Workshop 安装的 RitsuLib DLL 时被系统代码完整性策略阻止，导致模组加载失败。
可能原因	高置信度：当前 Workshop 发布 DLL 未满足本机 SAC/WDAC 的企业签名级别要求；仓库发布与 Workshop 流程中未看到 Windows DLL Authenticode 签名步骤。中等置信度：Steam Workshop 路径/来源信誉不足使 SAC 更严格处理该 DLL。
可能解决方案	在发布流水线中评估并加入 Windows 代码签名/时间戳步骤，确保上传到 GitHub Release 与 Steam Workshop 的最终 DLL/ZIP 内容一致且已签名；短期可在文档或 issue 回复中说明 SAC/WDAC 环境下的限制与可验证的规避方式。

展开详细分析、证据与验证

问题描述

期望行为

• 议题未显式填写「期望行为」，但从描述可理解为：通过 Steam 创意工坊安装 RitsuLib 后，启动游戏并进入模组加载流程时应能正常加载该 DLL。

实际行为

• 模组加载器报 System.IO.FileLoadException: Could not load file or assembly ... STS2-RitsuLib.dll。
• Windows 返回「应用程序控制策略已阻止此文件。 (0x800711C7)」。
• Windows 代码完整性日志记录事件 ID 3077，提示 SlayTheSpire2.exe 尝试加载的 STS2-RitsuLib.dll 不满足 Enterprise signing level requirements 或违反代码完整性策略。

复现步骤

1. 通过 Steam 创意工坊订阅并安装 STS2-RitsuLib。
2. 启动《杀戮尖塔 2》并进入模组加载流程。
3. 右下角显示加载 0 个模组并出现错误。
4. 日志显示 FileLoadException 与 0x800711C7。
5. 打开 Windows「事件查看器」，可看到 Code Integrity 事件 ID 3077。

环境与版本

• OS：Windows 11。
• 系统策略：已开启「智能应用控制」。
• 安装来源：Steam 创意工坊版 STS2-RitsuLib。
• Workshop 项目 ID：3747602295。
• RitsuLib 版本：未填写。
• 游戏版本 / 模组加载器版本：未提供。

日志、附件与原文摘录

• 原文：

  应用程序控制策略已阻止此文件。 (0x800711C7)

  要点：错误来自 Windows 应用控制/代码完整性层，发生在 CLR 加载 DLL 之前或期间。

• 原文：

  did not meet the Enterprise signing level requirements or violated code integrity policy

  要点：系统判定该 DLL 不满足当前策略要求，优先排查签名、时间戳、发布来源与最终上传产物。

详细分析依据

• mod_manifest.json:8 与 mod_manifest.json:9 显示 RitsuLib 是 has_pck: false、has_dll: true 的 DLL 型模组，因此 Windows 对 DLL 载入的代码完整性判断会直接影响可用性。
• 主项目输出目标为 net9.0 并启用动态加载：STS2-RitsuLib.csproj:29、STS2-RitsuLib.csproj:32。这些设置解释了为什么失败表现为 .NET FileLoadException，但不直接说明业务 API 逻辑有误。
• Release 工作流在 Ubuntu 上构建并发布 GitHub Release/NuGet：.github/workflows/release.yml:19、.github/workflows/release.yml:36、.github/workflows/release.yml:40、.github/workflows/release.yml:47；该片段未体现 Windows Authenticode 签名或时间戳步骤。
• CI 构建脚本调用 release_cli --artifacts-only 生成产物：scripts/ci/ci_build.py:47、scripts/ci/ci_build.py:62；打包函数使用 dotnet pack 并复制 DLL 到 bundle staging：scripts/release_lib/nuget.py:187、scripts/release_lib/nuget.py:231、scripts/release_lib/nuget.py:48、scripts/release_lib/nuget.py:55，未见签名步骤。
• Workshop 上传流程会把 bundle staging 复制到 content 并调用 ModUploader.exe upload：scripts/release_lib/workshop.py:147、scripts/release_lib/workshop.py:169、scripts/release_lib/workshop.py:204、scripts/release_lib/workshop.py:208；这里也未见在上传前对 DLL 做签名验证或签名处理。
• export_presets.cfg:31 中 codesign/enable=false 是 Godot Windows 导出预设的代码签名配置；本项目是 DLL 模组，不一定使用 Godot 导出生成 Workshop DLL，但该配置同样说明仓库中没有现成启用的 Windows 代码签名路径。
• 因此，较可能的维护方向不是修改 area/api 下的公开 API 行为，而是检查发布/分发链路：最终 Workshop 项目 3747602295 中的 STS2-RitsuLib.dll 是否 unsigned、是否与 GitHub Release 产物一致、是否需要 EV/OV 代码签名证书及时间戳来满足 SAC/WDAC。

反馈规范性提醒

维度	状态
复现步骤	已提供：包含 Workshop 安装、启动游戏、加载失败、事件查看器检查。
期望/实际	含糊：实际错误充分；期望行为字段为空，只能从上下文推断。
环境与版本	含糊：提供 Windows 11、SAC、Workshop ID；缺 RitsuLib 版本、游戏版本、模组加载器版本。
日志/附件	含糊：提供关键错误与 Code Integrity 摘录；日志 / 堆栈 代码块为空，缺完整加载器日志。
标题与背景	已提供：标题与正文聚焦 Windows 11 阻止 DLL，背景基本匹配。

详细验证建议

• 从 Steam Workshop 项目 3747602295 下载当前实际发布内容，记录 STS2-RitsuLib.dll 的 SHA-256，并与 GitHub Release/CI artifact 中对应 DLL 对比。
• 在 Windows 上对 Workshop DLL 运行签名检查（例如文件属性「数字签名」页或 Get-AuthenticodeSignature），确认是否 unsigned、签名无效、证书链不受信或缺时间戳。
• 在启用 SAC/WDAC 的 Windows 11 设备或等价测试策略下，用当前 Workshop 包复现事件 ID 3077。
• 若加入代码签名，确认签名发生在所有 DLL 都进入 bundle staging 之后、Workshop 上传之前；重新上传后再验证 FileLoadException 是否消失。
• 同步检查 GitHub Release zip、NuGet 包内 runtime DLL、Workshop content 三处是否存在签名状态不一致。

风险与未决

• Windows SAC/WDAC 的接受条件可能与证书类型、文件声誉、下载来源和组织策略有关；即使普通 Authenticode 签名存在，也需要在目标策略下验证。
• 报告者未提供 RitsuLib 精确版本、游戏版本与模组加载器完整日志，暂不能判断是否只影响当前 Workshop 上传批次或某个版本。
• 若项目无法提供 Windows 代码签名证书，短期可能只能文档化限制，并引导受影响用户使用管理员认可的路径或策略例外。
• 当前标签包含 area/api，但现有证据更偏向发布/分发/平台兼容问题；维护者可考虑改到相应的 release/distribution/platform area（若仓库标签存在）。

---

English translation

Summary

This issue appears to be Windows 11 Smart App Control / Code Integrity blocking the Steam Workshop STS2-RitsuLib.dll during load, returning 0x800711C7. For users with that policy enabled, RitsuLib becomes completely unloadable, but the evidence points more toward release artifact trust/signing than a public API runtime bug.

Maintainers should first verify whether the Workshop artifact has a Windows-acceptable Authenticode signature and, if needed, adjust the release/Workshop pipeline; the reporter should also provide exact versions and the full mod loader log to confirm scope.

Key Takeaways

Item	Takeaway
Brief description	With Windows 11 Smart App Control enabled, the game process is blocked by system Code Integrity when loading the Workshop-installed RitsuLib DLL, so mod loading fails.
Likely cause	High confidence: the current Workshop DLL does not satisfy the local SAC/WDAC enterprise signing-level requirement; the inspected release and Workshop pipeline snippets do not show a Windows DLL Authenticode signing step. Medium confidence: the Steam Workshop path/source reputation may make SAC treat the DLL more strictly.
Possible fix	Evaluate and add Windows code-signing/timestamping to the release pipeline, ensuring the final DLL/ZIP uploaded to GitHub Release and Steam Workshop is the signed artifact; in the short term, document the SAC/WDAC limitation and any verifiable workaround in the issue or docs.

Expand detailed analysis, evidence, and verification

Problem Description

Expected behavior

• The issue does not explicitly fill in the expected behavior field, but the description implies that after installing RitsuLib through Steam Workshop, the DLL should load normally during the game's mod-loading flow.

Actual behavior

• The mod loader reports System.IO.FileLoadException: Could not load file or assembly ... STS2-RitsuLib.dll.
• Windows returns “Application control policy has blocked this file. (0x800711C7)”.
• Windows Code Integrity logs event ID 3077, saying that SlayTheSpire2.exe tried to load STS2-RitsuLib.dll, but the DLL did not meet Enterprise signing level requirements or violated Code Integrity policy.

Reproduction steps

1. Subscribe to and install STS2-RitsuLib through Steam Workshop.
2. Start Slay the Spire 2 and enter the mod-loading flow.
3. The bottom-right indicator shows 0 mods loaded and an error appears.
4. Logs show FileLoadException and 0x800711C7.
5. Open Windows Event Viewer and find Code Integrity event ID 3077.

Environment and Versions

• OS: Windows 11.
• System policy: Smart App Control enabled.
• Install source: Steam Workshop version of STS2-RitsuLib.
• Workshop item ID: 3747602295.
• RitsuLib version: not provided.
• Game version / mod loader version: not provided.

Logs, Attachments, and Original Excerpts

• Original:

  应用程序控制策略已阻止此文件。 (0x800711C7)

  Key point: the error originates from Windows application-control / Code Integrity before or during CLR DLL loading.

• Original:

  did not meet the Enterprise signing level requirements or violated code integrity policy

  Key point: the system judged the DLL as not satisfying the current policy, so signing, timestamping, distribution source, and final uploaded artifact should be checked first.

Detailed Analysis Basis

• mod_manifest.json:8 and mod_manifest.json:9 show that RitsuLib is a DLL mod with has_pck: false and has_dll: true, so Windows Code Integrity decisions on DLL loading directly affect availability.
• The main project targets net9.0 and enables dynamic loading at STS2-RitsuLib.csproj:29 and STS2-RitsuLib.csproj:32. These settings explain why the failure appears as a .NET FileLoadException, but they do not by themselves indicate a public API logic bug.
• The release workflow builds on Ubuntu and publishes GitHub Release/NuGet artifacts: .github/workflows/release.yml:19, .github/workflows/release.yml:36, .github/workflows/release.yml:40, and .github/workflows/release.yml:47; this snippet does not show a Windows Authenticode signing or timestamping step.
• The CI build script invokes release_cli --artifacts-only to generate artifacts at scripts/ci/ci_build.py:47 and scripts/ci/ci_build.py:62; the packaging code runs dotnet pack and copies DLLs into bundle staging at scripts/release_lib/nuget.py:187, scripts/release_lib/nuget.py:231, scripts/release_lib/nuget.py:48, and scripts/release_lib/nuget.py:55, with no signing step visible.
• The Workshop upload flow copies bundle staging into content and calls ModUploader.exe upload: scripts/release_lib/workshop.py:147, scripts/release_lib/workshop.py:169, scripts/release_lib/workshop.py:204, and scripts/release_lib/workshop.py:208; it also does not show signature verification or signing before upload.
• export_presets.cfg:31 sets codesign/enable=false for the Godot Windows export preset. This project is a DLL mod and may not use Godot export to produce the Workshop DLL, but the setting still indicates that there is no ready enabled Windows code-signing path in the repository.
• Therefore, the more likely maintainer action is not changing behavior under area/api, but checking the release/distribution chain: whether the final STS2-RitsuLib.dll in Workshop item 3747602295 is unsigned, whether it matches the GitHub Release artifact, and whether EV/OV code signing plus timestamping is needed for SAC/WDAC.

Issue Hygiene Reminder

Dimension	Status
Reproduction steps	Provided: includes Workshop install, game start, load failure, and Event Viewer check.
Expected/actual	Ambiguous: actual error is detailed; the expected behavior field is empty and must be inferred.
Environment and versions	Ambiguous: Windows 11, SAC, and Workshop ID are provided; RitsuLib version, game version, and mod loader version are missing.
Logs/attachments	Ambiguous: key error text and Code Integrity excerpt are provided; the Logs / stack code block is empty and the full loader log is missing.
Title and background	Provided: title and body both focus on Windows 11 blocking the DLL.

Detailed Verification Suggestions

• Download the currently published contents of Steam Workshop item 3747602295, record the SHA-256 of STS2-RitsuLib.dll, and compare it with the corresponding DLL from GitHub Release / CI artifacts.
• On Windows, check the Workshop DLL signature status, for example via the file Properties “Digital Signatures” tab or Get-AuthenticodeSignature, to determine whether it is unsigned, invalid, untrusted, or missing timestamping.
• Reproduce event ID 3077 on a Windows 11 device with SAC/WDAC enabled or under an equivalent test policy using the current Workshop package.
• If code signing is added, confirm that signing happens after all DLLs enter bundle staging and before Workshop upload; after re-uploading, verify that the FileLoadException disappears.
• Check for signature-state mismatches across GitHub Release zip, NuGet runtime DLLs, and Steam Workshop content.

Risks and Open Questions

• Windows SAC/WDAC acceptance may depend on certificate type, file reputation, download source, and organizational policy; even an Authenticode-signed DLL should be tested under the target policy.
• The reporter did not provide exact RitsuLib version, game version, or the full mod loader log, so it is not yet clear whether only the current Workshop upload batch or a specific version is affected.
• If the project cannot provide a Windows code-signing certificate, the short-term path may be to document the limitation and direct affected users to administrator-approved paths or policy exceptions.
• The current labels include area/api, but the available evidence points more toward a release/distribution/platform compatibility issue; maintainers may consider moving it to the appropriate release/distribution/platform area if such labels exist.

---

工具侧记录

• BAKAOLC/STS2-RitsuLib#93 · 退出码 0 · 进程 171.43s
• gpt-5.5(high) · API 167885ms · 26 轮 · ↓86012 ↑7097 · 缓存读264704 写0 · $0.7398
• MCP available: management tools exposed to Claude.