由于不支持的 API FindFirstFileEx（WACK 在本地传递）导致 UWP 应用提交失败

Posted 2023-03-25

【中文标题】由于不支持的 API FindFirstFileEx（WACK 在本地传递）导致 UWP 应用提交失败

【英文标题】：UWP app submission failure due to unsupported API FindFirstFileEx (WACK passes locally)

【发布时间】：2017-12-30 12:00:22

【问题描述】：

我的 Xamarin.Forms 解决方案中包含一个 UWP 项目。在本地运行 Windows 应用程序证书工具包时，它会顺利通过。

将我的应用提交到商店时，认证过程失败并出现以下错误：

发现错误：

支持的 API 测试检测到以下错误：

此应用程序类型不支持 api-ms-win-core-file-l1-2-0.dll 中的 API FindFirstFileEx。 PInvoke.Kernel32.dll 调用此 API。

如果不修复会产生影响：

使用不属于 Windows SDK for Windows Store 应用的 API 违反了 Windows Store 认证要求。

如何解决：

查看错误消息以确定不属于适用于 Windows 应用商店应用的 Windows SDK 的 API。请注意，在调试配置中构建或未启用 .NET Native（如果适用）的应用程序可能无法通过此测试，因为这些环境可能会引入不受支持的 API。在发布配置中重新测试您的应用，并启用 .NET Native（如果适用）。

我已验证我的应用在发布模式下运行，并已验证我的 UWP 构建设置：

我尝试联系 Microsoft 的聊天支持，但被重定向到输入事件报告，然后我被重定向到仅在论坛上寻求帮助或支付高级技术支持，因此我无法获得更多有关这是否是有效失败的信息。

根据 FindFirstFileEx (https://msdn.microsoft.com/en-us/library/windows/desktop/aa364419(v=vs.85).aspx) 上的文档，Windows 桌面、应用商店应用和 Windows Phone 似乎都支持它。我的 UWP 应用提交支持桌面和移动家庭，似乎包含在此功能支持的客户端中，因此不清楚是什么导致了失败。

关于从这里去哪里有什么想法吗？

【问题讨论】：

今天我从 Microsoft 支持部门获悉，此问题已得到纠正。重新提交后，我的应用现在似乎已通过认证，因为它们处于“发布”状态。

【参考方案1】：

2017 年 8 月 14 日更新：这个问题现在应该在商店中得到解决。如果您遇到此问题，请尝试重新提交您的应用。

---

这是 WACK 扫描在 Store 中运行的方式以及它如何与 .NET Native 集成的问题。

在某些背景下，Windows 实际上没有名为 FindFirstFileEx 的 API - 它不存在。 WACK 支持的 API 扫描的工作方式是查看您调用的所有 API 并验证以下情况之一是否为真：

它是由您的包中的另一个 DLL 导出的 API 这是允许列表中明确提及的 API

对于kernel32.dll!FindFirstFileEx，WACK 发现您的包中不存在kernel32.dll，因此它必须检查允许列表。允许列表没有提到FindFirstFileEx，因为它不存在。以下是确实存在的内容：

C:\Program Files (x86)\Windows Kits\10\App Certification Kit>findstr FindFirstFileEx SupportedAPIs-x64.xml
    <API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-1-0.dll"/>
    <API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-2-0.dll"/>
    <API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-2-1.dll"/>
    <API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-2-2.dll"/>
    <API Name="FindFirstFileExA" ModuleName="api-ms-win-downlevel-kernel32-l1-1-0.dll"/>
    <API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-1-0.dll"/>
    <API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-2-0.dll"/>
    <API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-2-1.dll"/>
    <API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-2-2.dll"/>
    <API Name="FindFirstFileExW" ModuleName="api-ms-win-downlevel-kernel32-l1-1-0.dll"/>
    <API Name="FindFirstFileExA" ModuleName="kernel32.dll"/>
    <API Name="FindFirstFileExW" ModuleName="kernel32.dll"/> 

请注意，FindFirstFileExA 和 FindFirstFileExW 有很多条目，它们是实际存在的 API。每当您的应用程序尝试调用 FindFirstFileEx 时，它实际上是在调用其中之一。

对于 C/C++ 开发人员，预处理器实际上将FindFirstFileEx 替换为A 或W 版本based on the existence of the UNICODE macro。

对于 .NET 开发人员，JIT 运行时（或者，在 .NET Native 的情况下，编译器）会根据 DllImport attribute 的细节来确定是调用 A 还是 W 版本，例如CharSet 和 ExactSpelling 属性的值。

这就是问题所在 - 目前，商店中的 WACK 在 .NET 程序集上运行在编译器已将非后缀版本替换为正确的后缀版本。当您在开发机器上运行 WACK 时，它会在编译器进行替换后正确检查程序集，因此您看不到任何错误。

修复的第一部分（正在进行中）是将不带后缀的版本添加到允许列表中。修复的第二部分是确保 WACK 在后编译位上运行。

【讨论】：

感谢您的更新。我应该在提交前在“认证须知”部分添加注释，还是在认证失败后将其添加到“认证报告反馈”中？

我尝试在“认证备注”中添加备注，但似乎我仍然遇到了同样的失败......在初始认证失败并出现此错误后，有没有办法要求更仔细的审查？

我也有同样的问题。“每周发送更新”让我有点紧张。如果我无法在几周内发布更新，那就有点糟糕了。

MoveFileEx、FindFirstFileEx 和 FindNextFile 对我来说也是如此。在与严重的 .NET Native 错误 (***.com/questions/44850907/avoid-net-native-bugs) 作斗争后，我终于想在今天发布我的应用程序，但没有成功。将字符串添加到白名单需要多长时间？为什么微软在应用和应用商店方面做得如此糟糕？整个 .NET Native 仍然不成熟。但他们强迫我们使用它。

我刚刚了解到“认证说明”不适用于自动故障，抱歉。在部署修复程序之前，您应该通过聊天、电话或打开网络工单与 CSS 联系以寻求有关此故障的帮助。

【参考方案2】：

我遇到了同样的问题。按照 Peter Torr 的建议，我打开了一个聊天会话（来自开发中心）。

总结如下：

我：我的应用更新卡住了，因为您的认证系统存在错误。见这里：UWP app submission failure due to unsupported API FindFirstFileEx (WACK passes locally)

支持：我们已经意识到这个问题，并正在努力解决。给您带来的不便，我深表歉意

我：好的，我知道你正在处理这个错误。但与此同时，你可以让我的应用通过，对吧？

支持：我们有一个临时解决方法。如果您愿意，我可以为您获取这些信息？

...几分钟后...

支持：好的，所以我需要您重新提交您的包裹，但在证书部分的备注中包含此编号 XXXXXXXXXXXX。如果这不起作用并且您的应用再次未能通过证书，请提交有关最近失败的证书报告的反馈，并再次在其中插入编号。我已在您的帐户上注明以反映这一点

（实数替换为 XXXXXXXXXXX）

---

更新 1：就像@jkh 一样，自动认证再次失败，尽管数量有限。所以我在认证反馈中发布了这个数字。

更新 2：不幸的是，“解决方案”没有帮助。我现在已经给聊天支持的人写了一封电子邮件（聊天后我得到了他的地址）。我不太相信这会有所帮助。但是让我们看看...

更新 3：我还提交了一个事件。 （这可以在您通常开始聊天会话的地方完成，但使用下面的“提交事件”按钮。）

更新 4：来自事件提交的答案：

感谢您联系开发者支持。我了解到您因 Window Store Policy 15.1 的 API 错误而未能通过认证。经过进一步审查后，我想让您知道这是一个已知问题，目前正在由工程师进行修复。应该很快就会推出修复程序，请您稍候。如果周一之前未实施修复，我可以进一步调查此问题，但由于这是一个全球性问题，我建议等待修复推出。当我听到与修复有关的消息时，我一定会与您联系并要求您重试以获得认证。

更新 5：我重新提交了更新，现在正在等待结果。

更新 6：再次失败...

更新 7：事件提交的响应：这仍然是一个持续存在的问题，已将您的问题上报给我们的内部团队进行进一步调查，以尝试为您绕过此错误。一旦我收到更新，我一定会与您联系。

更新 8：最终，重新提交后，认证过程花了两天时间（！），但现在我的更新在商店里。哇，好吵啊……

【讨论】：

谢谢 - 我只是做了同样的事情，并获得了一个号码，可以添加到我的认证笔记中。它目前处于预处理阶段，所以我希望最好......

我的重新提交失败并出现同样的错误，即使在添加了聊天支持提供的参考号之后也是如此。我在认证报告反馈中添加了注释，将等待查看是否有任何进展。

到目前为止，认证报告反馈没有任何动静...似乎这种临时解决方法不起作用。你有更好的运气吗？

是的，我也一样。 :-(

这个问题肯定存在很多误解。认证报告反馈回复将我引导回聊天支持，然后他们告诉我重新提交带有参考号的认证报告反馈，并且反馈团队这次期待它。我刚刚收到最新的认证报告反馈回复，这只是一个通用回复，将我引导回聊天支持以处理 WACK 故障...

【参考方案3】：

我也面临同样的问题。已提交认证反馈报告，正在等待微软的一些回复...

【讨论】：

你的 API 函数 FindFirstFileEx 也一样吗？

功能一样，没错。

【参考方案4】：

在几周前向 Microsoft 开票后，我终于获得了对我的帐户的豁免，允许我通过自动认证。

请勿重新提交。我被告知要重新提交并提供有关该解决方案的认证报告反馈。重新提交几次后，收到邮件回复说我的提交是手动通过的，但是每次重新提交时这些提交都被删除了，所以我的应用仍然没有推送通过。

如果提交的内容包含您从 Microsoft 支持部门收到的编号（包含在认证说明和认证报告反馈中），并且在 Microsoft 处开具票证，您的提交最终将获得通过。