出现此问题的原因通常是 CSV 文件中的设备哈希格式不正确。 问题发生时，可以通过运行网络跟踪来确认问题。 如果网络跟踪中出现错误
400
，则 CSV 文件中的设备哈希格式很可能不正确。
400
错误消息的消息正文显示：
Cannot convert the literal '[DEVICEHASH]' to the expected type 'Edm.Binary'
损坏所收集哈希的任何内容都可能导致此错误。 一种可能性是哈希本身无法解码，即使哈希有效。
设备哈希为 Base64。 在设备级别，它编码为未填充的 Base64，但 Windows Autopilot 需要填充 Base64。 通常，有效负载不需要填充，并且进程可以工作。 但是，有时有效负载不会完全对齐，因此需要填充。 在这种情况下，会出现
400
错误消息。 PowerShell 的 Base64 解码器还要求填充 Base64，因此此解码器可用于验证哈希是否已正确填充。
哈希末尾的“A”字符实际上是空数据。 Base64 中的每个字符均为 6 位。 Base64 中的 6 位等于 0。 在末尾删除或添加
A
不会更改实际有效负载数据。
若要解决此问题并解决此问题，需要修改哈希。 然后需要测试新值，直到 PowerShell 成功解码哈希。 结果大多难以辨认，只要不显示
错误 Base-64 字符数组或字符串的长度无效
，就没问题。
若要测试 base64，请使用以下 PowerShell：
[System.Text.Encoding]::ascii.getstring( [System.Convert]::FromBase64String("DEVICE HASH"))
[System.Text.Encoding]::ascii.getstring( [System.Convert]::FromBase64String("Q29udG9zbwAAA"))
此特定示例不是设备哈希，而是未对齐的未装板 Base64，因此它适用于测试。
现在用于填充规则。 填充字符为“=”。 填充字符只能位于哈希的末尾，并且最多只能有两个填充字符。 下面是基本逻辑。
解码哈希是否失败？
是：最后两个字符是否为“=”？
是：将两个“=”替换为单个“A”字符，然后重试
否：在末尾添加另一个“=”字符，然后重试
此行为在意料之中。
消息 修复挂起 或 需要注意 可能还会显示在设备的 Windows Autopilot 设备 页中。 这些消息指示设备上发生了硬件更改。 选择 “修复挂起 状态”的链接时，将显示以下消息：
We've detected a hardware change on this device. We're trying to automatically register the new hardware. You don't need to do anything now; the status will be updated at the next check in with the result.
若要解决此问题并解决此问题，请注销并重新注册设备。 有关详细信息，包括如何取消注册设备，请参阅以下文章：
取消注册设备。
