Windows 桌面应用认证要求
本文内容
欢迎使用!
应用资格
1. 应用兼容且可复原
2. 应用必须遵守 Windows 安全最佳做法
3. 应用支持 Windows 安全功能
4. 应用必须遵守系统重启管理器消息
5. 应用必须支持干净、可逆的安装
6. 应用必须对文件和驱动程序进行数字签名
7. 应用不会基于操作系统版本阻止安装或应用启动检查
8. 应用不会在安全模式下加载服务或驱动程序
9. 应用必须遵循用户帐户控制准则
10.默认情况下,应用必须安装到正确的文件夹
11. 应用必须支持多用户会话
12. 应用必须支持 x64 版本的 Windows
结论
修订历史记录
详细了解桌面应用认证
另请参阅
显示另外 14 个
文档版本: 10
文档日期: 2015 年 7 月 29 日
本文档包含桌面应用必须满足的技术要求和资格资格,才能参与Windows 10桌面应用认证计划。
Windows 平台支持广泛的产品和合作伙伴生态系统。 在产品上显示 Windows 徽标表示 Microsoft 与你的公司之间关系和对质量的共同承诺。 客户信任你的产品上的 Windows 品牌,因为它可确保它符合兼容性标准,并在 Windows 平台上表现良好。 成功通过 Windows 应用认证允许在 Windows 兼容性中心展示你的应用,并且你可以在你的网站上显示认证徽标。
Windows 应用认证计划由计划和技术要求组成,以帮助确保携带 Windows 品牌的第三方应用在运行 Windows 的电脑上易于安装且可靠。 客户重视他们购买的系统的稳定性、兼容性、可靠性、性能和质量。 Microsoft 专注于投资,以满足设计为在适用于电脑的 Windows 平台上运行的软件应用的这些要求。 这些工作包括兼容性测试,以便在运行 Windows 软件的电脑上实现体验一致性、提高性能和增强安全性。 Microsoft 兼容性测试是与行业合作伙伴合作设计的,并不断改进以响应行业发展和消费者需求。
Windows 应用认证工具包用于验证是否符合这些要求,并替换用于在 Windows 7、Windows 8或Windows 8.1上验证的任何早期版本的工具包。 Windows 应用认证工具包是适用于Windows 10的 Windows 软件开发工具包 (SDK) 中包含的组件之一。
对于符合Windows 10桌面应用认证的应用,它必须满足以下条件和本文档中列出的所有技术要求。
它必须是独立应用
它必须在本地Windows 10电脑上运行
它可以是经过认证的 Windows Server 应用的客户端组件
它必须是代码和功能完整
它不得通过本地机制(包括通过文件和注册表项)与 Windows 应用商店应用通信,除非在受支持的企业方案中
它不得危及或损害 Windows 系统的安全性或功能
它必须具有唯一的名称,并且不得由其他人注册商标
所有外部组件必须单独认证或符合 Windows 应用认证工具包
对于任何捆绑应用,它必须具有选择退出选项
如果桌面应用提交到防病毒和/或反间谍软件 (即反恶意软件) 产品类别,则它必须遵守反恶意软件平台指南。 在提交之前,WINDOWS 10 反恶意软件 API 许可证和列表协议必须已签署并生效。 合作伙伴必须是协议中列出的组织的成员,或者拥有其成员和在协议中列出的组织中信誉良好的研究人员。 该功能必须由协议中列出的组织在Windows 10上认证。 应用必须在过去 12 个月内至少经过一次测试,并经过检测和清洁认证。
应用崩溃或停止响应的时间会导致用户非常沮丧。 应用应具有复原能力和稳定性,消除此类故障有助于确保软件更具可预测性、可维护性、性能和可信度。
1.1 你的应用不得依赖于 Windows 兼容性模式、AppHelp 消息或任何其他兼容性修补程序
1.2 你的应用必须具有兼容性清单,并为受支持的 Windows 版本使用适当的 GUID
1.3 你的应用必须通过使用应用程序的程序集清单而不是调用 SetProcessDPIAware 来感知 DPI
1.4 你的应用不得依赖于 VB6 运行时
1.5 你的应用不得加载任意 DLL 来截获使用 HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls的 Win32 API 调用。
使用 Windows 安全最佳做法有助于避免暴露在 Windows 攻击面上。 攻击面是恶意攻击者可以利用目标软件中的漏洞来利用操作系统的入口点。 最严重的安全漏洞之一是特权提升。
请注意,测试 2.1 2.6 仅适用于在 Windows 7、Windows 8 或 Windows 8.1 上测试的桌面应用。
2.1 你的应用必须使用强且适当的 ACL 来保护可执行文件
2.2 你的应用必须使用强且适当的 ACL 来保护目录
2.3 你的应用必须使用强且适当的 ACL 来保护注册表项
2.4 你的应用必须使用强且适当的 ACL 来保护包含对象的目录
2.5 你的应用必须减少对易受篡改的服务的非管理员访问
2.6 应用必须防止具有快速重启的服务每 24 小时重启两次以上
注意:应仅向需要访问权限的实体授予访问权限。
Windows 应用认证计划将通过验证 ACL 和服务是否以不会使 Windows 系统处于风险中的方式实现来验证 Windows 攻击面是否未公开。
Windows 操作系统具有许多支持系统安全和隐私的功能。 应用必须支持这些功能才能维护操作系统的完整性。 编译不当的应用可能会导致缓冲区溢出,进而可能导致拒绝服务或允许恶意代码执行。
3.1 你的应用不得使用 AllowPartiallyTrustedCallersAttribute (APTCA) 来确保对强名称程序集的安全访问
3.2 必须使用 /SafeSEH 标志编译应用,以确保安全异常处理
3.3 必须使用 /NXCOMPAT 标志编译应用,以防止数据执行
3.4 必须使用 /DYNAMICBASE 标志编译应用,以便将地址空间布局随机化 (ASLR)
3.5 你的应用不得读取/写入共享 PE 分区
当用户启动关闭时,他们通常强烈希望看到关闭成功;他们可能急于离开办公室,只是希望他们的电脑关闭。 应用必须通过不阻止关闭来尊重此需求。 虽然在大多数情况下,关闭可能并不重要,但应用必须做好应对严重关闭的准备。
4.1 你的应用必须正确处理关键关闭 在严重关闭中,返回 FALSE WM_QUERYENDSESSION 的应用将WM_ENDSESSION并关闭,而响应WM_QUERYENDSESSION超时的应用将终止。
4.2 GUI 应用必须立即返回 TRUE,以便准备重启 WM\_QUERYENDSESSION,LPARAM = ENDSESSION\_CLOSEAPP (0x1) 。
控制台应用可以调用 SetConsoleCtrlHandler 来指定将处理关闭通知的函数。 服务应用可以调用 RegisterServiceCtrlHandlerEx 来指定将接收关闭通知的函数。
4.3 你的应用必须在 30 秒内返回 0 并关闭 WM\_ENDSESSION,LPARAM = ENDSESSION\_CLOSEAPP (0x1) 。
应用至少应通过保存任何用户数据来准备,并声明重启后所需的信息。
4.4 接收 CTRL\_C\_EVENT 通知的控制台应用应立即关闭 4.5 驱动程序不得否决系统关闭事件
注意:由于无法中断的操作而必须阻止关闭的应用应向用户解释原因。 使用 ShutdownBlockReasonCreate 注册一个向用户解释原因的字符串。 操作完成后,应用应调用 ShutdownBlockReasonDestroy 以指示可以关闭系统。
干净、可逆的安装允许用户成功管理 (在其系统上部署和删除) 应用。
5.1 你的应用必须正确实现干净、可逆的安装 如果安装失败,应用应该能够回滚它并将计算机还原到以前的状态。
5.2 你的应用不得强制用户立即重新启动计算机 在安装、卸载或更新结束时,重启计算机不应是唯一的选项。 用户应有机会稍后重启。
5.3 你的应用不得依赖于 8.3 短文件名 (SFN) 5.4 你的应用不得阻止无提示安装/卸载 5.5 应用安装程序必须创建正确的注册表项才能成功检测和卸载 Windows 清单工具和遥测工具需要有关已安装应用的完整信息。 如果使用基于 MSI 的安装程序,MSI 会自动创建以下注册表项。 如果不使用 MSI 安装程序,则安装模块必须在安装过程中创建以下注册表项:
DisplayName
InstallLocation
Publisher
UninstallString
VersionMajor 或 MajorVersion
VersionMinor 或 MinorVersion
5.6 卸载后,应用必须从“添加/删除程序”中删除其所有条目
验证码数字签名允许用户确保软件是正版软件。 它还允许检测文件是否已被篡改,例如是否被病毒感染。 内核模式代码签名强制实施是一项称为代码完整性的 Windows 功能, (CI) ,它通过在每次将文件映像加载到内存时验证文件的完整性来提高操作系统的安全性。 CI 检测恶意代码是否修改了系统二进制文件。 当内核模块的签名无法正确验证时,还会生成诊断和系统审核日志事件。
6.1 所有可执行文件 (.exe、.dll、.ocx、.sys、.cpl、.drv、.scr) 都必须使用 Authenticode 证书进行签名
6.2 应用安装的所有内核模式驱动程序都必须具有通过 Windows 硬件认证计划获取的 Microsoft 签名。 所有文件系统筛选器驱动程序都必须由 Microsoft 签名。
6.3 例外和豁免 仅对未签名的第三方可再发行组件(不包括驱动程序)考虑豁免。 若要授予此豁免,需要一份通信证明,请求签名版本的可再发行 () 。
7. 应用不会基于操作系统版本阻止安装或应用启动检查
当没有任何技术限制时,不要人为地阻止客户安装或运行其应用,这一点很重要。 通常,如果应用是为 Windows Vista 或更高版本的 Windows 编写的,则它们不必检查操作系统版本。
7.1 你的应用不得对相等性执行版本检查 如果需要特定功能,检查该功能本身是否可用。 如果需要 Windows 7,检查适用于 Windows 7 或更高版本 (>= 6.2) 。 这样,检测代码将继续在 Windows 的未来版本上运行。 驱动程序安装程序和卸载模块绝不应检查操作系统版本。
7.2 对于满足以下条件的应用,将考虑例外和豁免:
作为一个包交付的应用,这些应用也在 Windows 7、Windows 8 和 Windows 8.1 上运行,并且需要检查操作系统版本来确定在给定操作系统上安装哪些组件。
仅检查最低版本的操作系统的应用仅在安装期间 (,而不是在运行时) 仅使用已批准的 API 调用,并在应用清单中正确列出最低版本要求。
安全应用 (防病毒、防火墙等) 、系统实用工具 (例如碎片整理、备份和诊断工具) ,仅使用批准的 API 调用来检查操作系统版本。
安全模式允许用户诊断和排查 Windows 问题。 驱动程序和服务不得设置为在安全模式下加载,除非需要用于的基本系统操作(如存储设备驱动程序)或诊断和恢复目的(如防病毒扫描程序)。 默认情况下,当 Windows 处于安全模式时,它仅启动预装在 Windows 中的驱动程序和服务。
8.1 例外和豁免 必须在安全模式下启动的驱动程序和服务需要豁免。 豁免请求必须包括写入 SafeBoot 注册表项的每个适用的驱动程序或服务,并描述应用或服务必须在安全模式下运行的技术原因。 应用安装程序必须使用以下注册表项注册所有此类驱动程序和服务:
- HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal - HKLM/System/CurrentControlSet/Control/SafeBoot/Network
注意: 必须测试这些驱动程序和服务,以确保它们在安全模式下运行而不会发生任何错误。
某些 Windows 应用在管理员帐户的安全上下文中运行,并且应用通常请求过多的用户权限和 Windows 特权。 通过控制对资源的访问,用户可以控制其系统,并保护他们免受不必要的更改。 不需要的更改可能是恶意更改,例如控制计算机的 rootkit,或者是由具有有限权限的人员执行操作的结果。 控制对资源的访问的最重要规则是为用户提供执行其必要任务所需的最低访问标准用户上下文。 遵循用户帐户控制 (UAC) 指南为应用提供应用所需的权限,而不会使系统不断面临安全风险。 大多数应用在运行时不需要管理员权限,并且应该以标准用户身份正常运行。
9.1 应用必须具有定义执行级别的清单,并告知操作系统应用需要哪些权限才能运行 应用清单标记仅适用于 EXE,不适用于 DLL。 这是因为 UAC 不会在进程创建期间检查 DLL。 值得注意的是,UAC 规则不适用于 Microsoft 服务。 清单可以是嵌入的,也可以是外部的。
若要创建清单,请创建名为 <app_name>.exe.manifest 的文件,并将其存储在 EXE 所在的目录中。 请注意,如果应用具有内部清单,则忽略任何外部清单。 例如:
<requestedExecutionLevel level=“”asInvoker |highestAvailable |requireAdministrator“” uiAccess=“”true|false“”/>
9.2 应用main进程必须以标准用户身份运行, (作为Invoker) 。 必须将任何管理功能移动到使用管理权限运行的单独进程中。 面向用户的应用(例如通过“开始”菜单上的程序组访问的应用)和需要提升的应用必须经过 Authenticode 签名。
9.3 例外和豁免 对于使用提升的权限运行其main进程的应用,需要豁免 (requireAdministrator 或 highestAvailable) 。 main进程被标识为应用的用户入口点。 对于以下情况,将考虑豁免:
执行级别设置为 highestAvailable 和/或 requireAdministrator 的管理或系统工具
只有辅助功能或 UI 自动化框架应用将 uiAccess 标志设置为 true,以绕过用户界面特权隔离 (UIPI) 。 若要正确启动应用利用率,此标志必须是验证码签名的,并且必须驻留在文件系统中的受保护位置,即 Program Files。
用户应使用文件的默认安装位置获得一致且安全的体验,同时保留在其所选位置安装应用的选项。 还需要将应用数据存储在正确的位置,以便多人使用同一台计算机,而不会损坏或覆盖彼此的数据和设置。 Windows 在文件系统中提供特定位置,用于存储特定于用户的程序和软件组件、共享应用数据和应用数据
10.1 默认情况下,应用必须安装在 Program Files 文件夹中 对于 %ProgramFiles% 中的本机 32 位和 64 位应用,对于在 x64 上运行的 32 位应用,%ProgramFiles (x86) %。 用户数据或应用数据不得存储在此位置,因为为此文件夹配置了安全权限。
10.2 你的应用必须避免在启动时自动启动 例如,你的应用不应设置以下任何内容:
在 Software\Microsoft\Windows\CurrentVersion 下,注册表运行项 HKLM 和 或 HKCU
Software\Wow6432Node\Microsoft\windows\CurrentVersion 下的注册表运行项 HKLM 和 或 HKCU
“开始”菜单全部程序 > 启动
10.3 你的应用数据(必须在计算机上的用户之间共享)应存储在 ProgramData 10.4 中,你的应用数据是特定用户独占且不与计算机的其他用户共享的,必须存储在 Users\\<username>\\AppData 10.5 你的应用不得直接写入“Windows”目录和或子目录 使用正确的方法来安装文件,如字体或驱动程序。
10.6 你的应用必须在首次运行时写入用户数据,而不是在每台计算机安装过程中写入用户数据 安装应用后,没有存储数据的正确用户位置。 安装后,应用尝试在计算机级别修改默认关联行为将失败。 相反,必须在每用户级别声明默认值,这可以防止多个用户覆盖彼此的默认值。
10.7 例外和豁免 写入全局程序集缓存的应用需要豁免, (GAC) .NET 应用应将程序集依赖项保密,并将其存储在应用目录中,除非明确需要共享程序集。
Windows 用户应该能够运行并发会话,而不会发生冲突或中断。
11.1 应用必须确保在本地或远程多个会话中运行时,应用的正常功能不会受到不利影响
11.2 你的应用设置和数据文件不得在用户之间保留
11.3 必须将用户的隐私和首选项与用户的会话隔离
11.4 应用实例必须彼此隔离 这意味着一个实例中的用户数据对应用的另一个实例不可见。 不应在活动用户会话中听到非活动用户会话中的声音。 如果多个应用实例使用共享资源,则应用必须确保不存在冲突。
11.5 为多个用户安装的应用必须将数据存储在正确的文件夹中 () 和注册表位置 请参阅 UAC 要求。
11.6 用户应用必须能够在多个用户会话中运行, (本地和远程访问的快速用户切换) 11.7 你的应用必须为应用的现有实例检查其他终端服务 (TS) 会话
注意: 如果应用不支持多个用户会话或远程访问,则必须在从此类会话启动时明确说明这一点。
12. 应用必须支持 x64 版本的 Windows
随着 64 位硬件越来越普遍,用户希望应用开发人员通过将其应用迁移到 64 位来利用 64 位体系结构的优势,或者 32 位版本的应用在 64 位版本的 Windows 下运行良好。
12.1 你的应用必须本机支持 64 位,或者至少基于 32 位 Windows 的应用必须在 64 位系统上无缝运行,以保持与 64 位版本的 Windows 的兼容性
12.2 你的应用及其安装程序不得包含任何 16 位代码或依赖于任何 16 位组件
12.3 应用安装程序必须检测并安装适用于 64 位体系结构的正确驱动程序和组件
12.4 任何 shell 插件必须在 64 位版本的 Windows 上运行
12.5 在 WoW64 模拟器下运行的应用不应尝试颠覆或绕过 Wow64 虚拟化机制 如果应用需要检测它们是否在 WoW64 模拟器下运行的特定方案,则应通过调用 IsWow64Process 来执行此操作。
随着这些要求的发展,我们将注意以下修订历史记录中的更改。 稳定的要求对于你尽最大努力至关重要,因此我们将致力于确保我们所做的更改是可持续的,并继续保护和增强你的应用。
再次感谢你一起致力于提供出色的客户体验。
展开表
Date
版本
修订说明
文档链接
2011 年 12 月 20 日
1.0
预览版文档的初始草稿。
2012 年 1 月 26 日
1.1
更新到第 2 节。
1.1
2012 年 5 月 31 日
1.2
添加了摘要测试结果
1.2
2012 年 6 月 29 日
3.0
Windows 8最终文档
3.0
2013 年 6 月 18 日
3.1
Windows 8.1文档
3.1
2014 年 2 月 20 日
3.2
内部更新
2014 年 3 月 18 日
3.3
Windows 8.1 更新 1
3.3
2015 年 7 月 29 日
10
Windows 10更新
10
展开表
要求
说明
兼容性和复原能力
崩溃&挂起对用户造成重大干扰,并造成挫折。 应用应具有复原能力和稳定性,消除此类故障有助于确保软件更具可预测性、可维护性、性能和可信度。 必须针对用户的应用入口点进行清单,以便实现兼容性,并声明正确的 GUID。 必须针对用户的应用入口点进行清单,以便获得高 DPI 感知,并且调用适当的 API 以支持高 DPI。 有关详细信息,请参阅:
遵循Windows 安全中心最佳做法
使用 Windows 安全最佳做法有助于避免暴露在 Windows 攻击面上。 攻击面是恶意攻击者可以利用目标软件中的漏洞来利用操作系统的入口点。 最严重的安全漏洞之一是特权提升。 有关详细信息,请参阅:
支持Windows 安全中心功能
Windows 操作系统已实施许多措施来支持系统安全和隐私。 应用程序必须支持这些措施才能维护 OS 的完整性。 编译不当的应用程序可能会导致缓冲区溢出,进而可能导致拒绝服务或恶意代码执行。 有关详细信息,请参阅 BinScope 工具参考 。
遵循系统重启管理器消息
当用户启动关闭时,在绝大多数情况下,他们强烈希望看到关闭成功;他们可能急于离开办公室,“只是想”他们的电脑关闭。 应用必须通过不阻止关闭来尊重此需求。 虽然在大多数情况下,关闭可能并不重要,但应用必须做好应对严重关闭的准备。
清理可逆安装
干净、可逆的安装允许用户成功管理 (在其系统上部署和删除) 应用。 有关详细信息,请参阅 如何:使用 ClickOnce 应用程序安装必备组件 。
对文件和驱动程序进行数字签名
验证码数字签名允许用户确保软件是正版软件。 它还允许检测文件是否已被篡改,例如,如果文件已被病毒感染。 内核模式代码签名强制实施是一项称为代码完整性的 Windows 功能, (CI) ,它通过在每次将文件映像加载到内存时验证文件的完整性来提高操作系统的安全性。 CI 检测恶意代码是否修改了系统二进制文件。 当内核模块的签名无法正确验证时,还会生成诊断和系统审核日志事件。
不要基于操作系统版本阻止安装或应用启动检查
当没有任何技术限制时,不要人为地阻止客户安装或运行其应用,这一点很重要。 通常,如果应用是为 Windows Vista 或更高版本编写的,则它们应该没有理由检查操作系统版本。 有关详细信息,请参阅 操作系统版本控制 。
不要在安全模式下加载服务和驱动程序
安全模式允许用户诊断和排查 Windows 问题。 除非系统的基本操作 ((例如,存储设备驱动程序) )或出于诊断和恢复目的 ((例如,防病毒扫描程序) )需要,否则驱动程序和服务不得设置为在安全模式下加载。 默认情况下,安全模式不会启动大多数未预装 Windows 的驱动程序和服务。 除非系统要求它们用于基本操作或诊断和恢复目的,否则它们应保持禁用状态。 有关详细信息,请参阅:
遵循用户帐户控制 (UAC) 准则
某些 Windows 应用在管理员帐户的安全上下文中运行,许多应用需要过多的用户权限和 Windows 特权。 通过控制对资源的访问,用户可以控制其系统免受不需要的更改 (不需要的更改可能是恶意的,例如 rootkit 偷偷接管计算机,或来自具有有限权限的人员的操作,例如,员工在工作计算机上安装了禁止的软件) 。 控制对资源的访问的最重要规则是为用户提供执行其必要任务所需的最低访问标准用户上下文。 遵循 UAC 指南在需要时为应用提供必要的权限,而不会使系统不断面临安全风险。 有关详细信息,请参阅:
默认安装到正确的文件夹
用户应使用文件的默认安装位置获得一致且安全的体验,同时保留将应用安装到所选位置的选项。 还需要将应用数据存储在正确的位置,以便多人使用同一台计算机,而不会损坏或覆盖彼此的数据和设置。 有关详细信息,请参阅 安装/卸载要求摘要 。
支持多用户会话
Windows 用户应该能够运行并发会话,而不会发生冲突或中断。 有关详细信息,请参阅 远程桌面服务编程指南 。
支持 x64 版本的 Windows
随着 64 位硬件越来越普遍,用户希望应用开发人员通过将应用迁移到 64 位来利用 64 位体系结构的优势,或者 32 位版本的应用在 64 位版本的 Windows 下运行良好。