我之前也遇到过一模一样的情况——用ConfuserEx混淆WPF入口EXE就崩溃，但单独混淆DLL完全正常。结合你的配置和生成事件来看，问题大概率出在过度保护干扰了WPF的特殊启动逻辑，或者路径配置有小疏漏，给你几个针对性的解决方案：

1. 先降低混淆强度，排查冲突保护 #

WPF的EXE不像普通类库，它包含了应用启动的引导代码和WPF元数据信息，aggressive预设里的某些保护（比如anti tamper）会直接修改PE文件结构，破坏WPF的初始化流程。你可以先调整配置，弱化混淆规则：

修改你的Confuser.crproj：

<project outputDir="..\Release" baseDir="obj\Release" xmlns="http://confuser.codeplex.com">
  <module path="Sample.exe" >
    <!-- 把aggressive换成normal，先保证程序能正常启动 -->
    <rule pattern="true" preset="normal" inherit="false">
      <protection id="anti ildasm" />
      <!-- 先注释掉anti tamper，这个是最容易和WPF冲突的保护 -->
      <!-- <protection id="anti tamper" /> -->
      <protection id="anti dump" />
    </rule>
  </module>
  <probePath>..\..\obj\Release</probePath>
  <probePath>..\..\bin\Release</probePath>
</project>

如果修改后能正常运行，再逐个把注释掉的保护加回来，就能精准定位到是哪个保护导致的崩溃。

2. 修正路径配置，避免依赖找不到 #

你的probePath用了..\..\obj\Release这种多层回退的路径，很可能ConfuserEx没正确找到依赖的DLL。如果你的Confuser.crproj放在项目根目录，直接用相对项目根的路径更稳妥：

<project outputDir="bin\Release" baseDir="obj\Release" xmlns="http://confuser.codeplex.com">
  <!-- 明确指定未混淆的EXE路径 -->
  <module path="obj\Release\Sample.exe" >
    <rule pattern="true" preset="normal" inherit="false">
      <protection id="anti ildasm" />
      <protection id="anti dump" />
    </rule>
  </module>
  <!-- 直接指向项目的编译输出目录 -->
  <probePath>obj\Release</probePath>
  <probePath>bin\Release</probePath>
</project>

这样ConfuserEx能准确找到需要混淆的文件和它的依赖项。

3. 调整生成后事件的执行时机 #

WPF项目编译时会生成一些临时文件，可能还没完全写入到bin\Release就触发了混淆，导致混淆的是不完整的文件。你可以给生成后事件加个短暂延迟：

把生成后事件命令改成：

if "$(ConfigurationName)" == "Release" (
  timeout /t 2 /nobreak >nul
  "$(ProjectDir)ConfuserEx\Confuser.CLI.exe" "$(ProjectDir)Confuser.crproj"
)

2秒的延迟足够让所有编译文件都写入完成了。

4. 排查崩溃细节（如果以上都没用） #

如果还是崩溃，去Windows事件查看器的应用程序日志里找崩溃的异常信息，或者用Visual Studio附加到崩溃的进程，看调用栈就能知道是哪个模块出问题了——大概率是某个保护修改了WPF必需的元数据。

最后总结 #

WPF EXE混淆崩溃的核心原因就是它的启动逻辑太特殊，过度的PE修改类保护会直接搞崩初始化流程。先从降低混淆强度、修正路径开始排查，基本都能解决问题。

内容的提问来源于stack exchange，提问作者Sharika