74 openlast updated

HomeOctober 2026 patch cycleKB5126836: Server 2012 R2 SAN disks vanish after update

Known issueEnterprisefrom 2026-10

Issue from: October 2026 Patch Tuesday: 1,413 fixes, one exploited zero-day, and an Exchange hangover

KB5126836: Server 2012 R2 SAN disks vanish after update

Part of October 2026 patch cycle

Vendor
Microsoft
Products
Windows Server 2012 R2 ESU (KB5126836)
Published
Status
Open

Call: Known issue. After the October Monthly Rollup for Windows Server 2012 R2, Fibre Channel SAN disks behind Microsoft MPIO can fail to start after the reboot. This is reported, not confirmed: one report, from one environment, on Microsoft Q&A. It’s a well-documented report, with a before-and-after comparison, but it’s still one. Microsoft hasn’t acknowledged it.

Why you still patch: KB5126836 is the final ESU rollup for 2012 R2. ESU ended on October 13. It also fixes CVE-2026-96951, the Windows Shell Mark-of-the-Web bypass that’s being exploited and is on CISA’s KEV list (due date October 16, already passed). Don’t expect a later fix for this storage problem. There are no more updates coming.

  • No FC/MPIO SAN storage: patch now.
  • FC/MPIO SAN storage: patch one node first, with the rollback planned before you start. If you roll back, isolate that server. It’s now missing the fix for an exploited flaw, and that won’t change.

What breaks: The first reboot can look fine. After the reboot that finishes the rollup:

  • Every SAN disk shows “This device cannot start (Code 10)” in Device Manager.
  • mpclaim -e reports “There is no enterprise storage connected.”
  • Disk Management shows only the boot disk.
  • The System log shows MPIO event 1 (disk created), then events 46 (path removed after a PnP event) and 17 (degraded) for every disk, all in the same second.

The HBA ports stay online, they see the storage ports, and every LUN path is discovered. The disks just won’t start.

What changed: The rollup installs a new disk class driver package. disk.sys and classpnp.sys go from 6.3.9600.18758 to 6.3.9600.23447, and partmgr.sys is replaced too. Nobody has proven which file is responsible.

Who’s hit: The one report is from Server 2012 R2 Standard (ESU) cluster nodes, on Dell PowerEdge rack servers with Emulex LPe35002 Fibre Channel HBAs, Microsoft MPIO with MSDSM, and a Dell EMC array using ALUA. The LUNs back an Oracle RAC/ASM cluster. Nobody has said whether QLogic HBAs are affected. The reporter’s evidence:

  • A server with identical hardware, whose rollup rolled back on its own after an Azure Arc connectivity failure, got its disks back.
  • A server without the October updates is fine.
  • Uninstalling KB5126836 brought back all eight disks, with both paths each.

Server 2012 (non-R2) and its rollup, KB5126835, are unaffected as far as anyone knows. We found no reports.

Microsoft’s status: Not on the Server 2012 R2 release health page, and not in KB5126836’s known issues. The only issue listed there is September’s USB audio Code 10 bug, which is unrelated. A Microsoft Q&A moderator called it a “clear correlation” and pointed the reporter to a paid support case.

Workaround:

  • Before you change anything, collect evidence:
    • %windir%\inf\setupapi.dev.log
    • the System and Setup event logs
    • mpclaim -e and mpclaim -s -d output
    • Device Manager status and hardware IDs for a few affected disks
    • file versions of disk.sys, classpnp.sys, partmgr.sys, mpio.sys, msdsm.sys and the HBA miniport
  • Move the cluster workload off the node cleanly. Don’t touch ASM LUNs, disk signatures or reservations while the disks show Code 10.
  • Uninstall KB5126836 (Programs and Features > View installed updates) and reboot. Confirm that MPIO lists every LUN and path, and that ASM sees its disks, before the node goes back into service.
  • Isolate the rolled-back server.
  • Ask your HBA vendor whether a driver and firmware pair is validated against disk.sys 6.3.9600.23447. Test that on a lab host first. It’s an idea, not a known fix.

Separately, Microsoft notes that the install itself can fail on Azure Arc-enabled servers if they can’t reach the ESU-only endpoints. Arc ESU licenses stopped working at midnight UTC on October 14, so a server that hasn’t installed this yet may not be able to.

Sources: Microsoft Q&A report, KB5126836, KB5126835, Server 2012 R2 release health, MSRC: CVE-2026-96951, Azure Arc ESU troubleshooting.

Sources

More from October 2026 patch cycle