IT之家 12 月 16 日消息，科技媒體 BornCity 今天（12 月 16 日）發(fā)布博文，報道稱微軟承認 12 月 9 日補丁星期二發(fā)布的累積更新存在 BUG，影響 Windows 10、Windows Server 系統(tǒng)，導致消息隊列（MSMQ）功能失效。

IT之家注：消息隊列就像是一個“電子郵箱”系統(tǒng)，但它是給電腦程序用的。當一個程序忙不過來時，可以先把任務（消息）扔進這個隊列里排隊，等有空了再處理，或者傳給另一臺電腦處理。其作用是保證數據不丟失，讓不同軟件之間能順暢溝通。

根據微軟發(fā)布的健康儀表板信息，引發(fā)故障的累積更新主要包括三個版本：

• 適用于 Windows 10 2019 Enterprise LTSC 和 Windows Server 2019 的 KB5071544；

• 適用于 Windows 10 22H2（含 ESU 許可）的 KB5071546；

• 適用于 Windows 10 1607 Enterprise LTSC 及 Windows Server 2016 的 KB5071543。

受影響的系統(tǒng)會出現多種異常癥狀，極具迷惑性，最為典型的是 MSMQ 隊列直接轉為“非活動”狀態(tài)，導致應用程序無法寫入數據。

此外還表現為 IIS 站點崩潰并提示“沒有足夠的資源執(zhí)行該操作”。系統(tǒng)日志中還會生成“磁盤空間或內存不足”的錯誤信息，即便服務器實際擁有充足的硬件資源。

在創(chuàng)建消息文件后，用戶可能會遇到針對 C:\Windows\System32\msmq\storage\*.mq 路徑的文件創(chuàng)建失敗錯誤。

微軟技術團隊指出，問題的根源在于更新補丁修改了 MSMQ 的安全模型及底層 NTFS 權限。具體而言，系統(tǒng)現在要求 MSMQ 用戶必須擁有對 C:\Windows\System32\MSMQ\storage 文件夾的寫入權限。然而，該文件夾的默認權限通常僅限于管理員組，這一變更導致普通用戶賬戶調用 MSMQ API 發(fā)送消息時被系統(tǒng)攔截，進而引發(fā)上述資源錯誤。

微軟目前正在緊急調查此問題，承諾將在找到解決方案或臨時緩解措施后公布更多信息。由于該故障嚴重影響集群 MSMQ 環(huán)境及高負載場景，建議受影響的企業(yè)管理員暫停部署相關更新，或密切關注微軟官方的后續(xù)公告。在官方修復發(fā)布前，手動調整相關文件夾權限可能是一個潛在的嘗試方向，但需謹慎操作以避免安全風險。

廣告聲明：文內含有的對外跳轉鏈接（包括不限于超鏈接、二維碼、口令等形式），用于傳遞更多信息，節(jié)省甄選時間，結果僅供參考，IT之家所有文章均包含本聲明。