.NET 6控制台程序A启动被阻止的B.exe为何有时成功有时失败？

核心原因 #

这个现象的本质是Windows SmartScreen安全机制与NTFS备用数据流（Zone.Identifier）的信任判断逻辑差异。从互联网下载的文件会被标记Zone.Identifier数据流（记录来源为互联网区域），SmartScreen会据此拦截未解除阻止的程序；而已解除阻止的程序启动其他程序时，系统是否传递信任、自动移除标记，取决于Windows版本、安全策略和文件位置等因素。

自动解除阻止/启动成功的场景 #

• Windows版本支持信任继承：Win10 1903及以后版本、Win11全版本，引入了进程信任上下文传递机制——已解除阻止的A.exe作为信任进程，启动同目录下的B.exe时，系统会自动识别二者属于同一分发包，移除B.exe的Zone.Identifier标记，允许无拦截启动。
• 同目录信任传递：A.exe和B.exe位于同一解压目录，且A已手动解除阻止，系统会将该目录的信任级别覆盖到同目录内其他文件，跳过SmartScreen的单独检查。
• 宽松安全策略环境：企业域环境中组策略放宽了SmartScreen限制，或用户手动降低了Windows Defender的安全级别，允许信任进程启动未解除阻止的关联程序。

需手动解除B.exe阻止的场景 #

• 旧Windows版本无信任继承：Win10 1903之前的版本没有实现进程信任传递逻辑，每个文件的Zone.Identifier标记是独立校验的，A.exe启动B.exe时会触发SmartScreen的标准拦截。
• 严格安全策略强制校验：企业域组策略强制要求所有互联网来源文件必须手动解除阻止，或SmartScreen设置为“严格”模式，禁止信任进程传递权限给未解除阻止的程序。
• 跨目录启动：B.exe不在A.exe的同一解压目录，系统无法判定二者属于同一分发包，不会传递信任，必须手动解除B的阻止。
• SmartScreen高风险判定：B.exe因未签名、属于少见程序等被SmartScreen标记为高风险，即使A已解除阻止，系统仍会拦截B的启动，要求手动操作。

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