Question

我有一个 Web 应用程序在 Azure 中运行，我有一些服务器无响应的中断。当我查看 IIS 日志时，我看到 HTTP 500 错误，sc-substatus为 121，sc-win32-status为 0。

省略所有其他字段，日志看起来像这样，按以下顺序：

sc-status sc-substatus sc-win32-status
500 121 0

我在网上找不到 500.121 错误的参考。

14

4

Answer 1

我刚从一个 Azure 软件工程师那里得到这个：

121 是一个超时事件，这基本上意味着请求在工作虚拟机上花费了 230 秒，而没有在连接上启动任何读 / 写 IO。

IIS 日志都有一个时间值徘徊在 230 秒左右。神秘解决了。

Answer 2

我们看到了同样的问题。

TLDR

我们在 Azure SQL 数据库中使用始终加密。

我们使用 Azure Key Vault 存储主密钥。

我们发现为旧版本的 Azure Key Vault 提供程序记录了以下错误-https://support.microsoft.com/en-us/help/4016853/fix-deadlock-when-apps-try-to-acquire-or-refresh-an-authentication-tok

解决方案-我们将 Azure Key Vault 提供程序从 1.x 版本升级到最新的 2.1.0 版本-https://www.nuget.org/packages/Microsoft.SqlServer.Management.AlwaysEncrypted.AzureKeyVaultProvider/2.1.0

Symptoms

我们开始生产 500 / 121。

所有响应时间都超过 230 秒。

问题总是相隔 2 小时发生...有时稍长。

Logging

我们自己的日志显示什么都没有。

ELMAH 什么也没显示。

失败的请求跟踪未显示任何内容。

唯一的指示是在 IIS 日志中。

我们还从 Azure 门户的应用服务中的诊断和解决问题选项卡中收集了一些.Net Profiler Traces，并包含了线程堆栈。我们注意到有许多线程堆栈正在做与 Always Encrypted 相关的事情。这只是有点奇怪，但这是最终让我们将 Always Encrypted 视为罪魁祸首的东西。

复制

这段代码在 4 个不同的环境中。

它只发生在两个环境中。

我们没有什么会导致它发生。

MS 支持问题

https://support.microsoft.com/en-us/help/4016853/fix-deadlock-when-apps-try-to-acquire-or-refresh-an-authentication-tok

请考虑以下情况：

You have Microsoft .NET Framework applications that use Always Encrypted in SQL Server 2016 or Azure SQL Database.
The column master keys for these applications are stored in the Azure Key Vault.

在这种情况下，应用程序会遇到死锁。因此，应用程序将变得无响应（挂起）或超时。

在尝试获取或刷新 Azure Key Vault 的身份验证令牌时可能会发生死锁。

Azure Key Vault Provider v2.1.0 发行说明

https://www.nuget.org/packages/Microsoft.SqlServer.Management.AlwaysEncrypted.AzureKeyVaultProvider/2.1.0

此版本解决了所有以前版本中存在的可能导致多线程应用程序死锁的错误。