Fix STATUS_WMI_READ_ONLY (0XC00002C6) on Windows

You get this error when a script or tool tries to write to a read-only WMI data item. The fix is to change the target to a writable WMI class or use the correct method.

You're trying to write to something that won't let you

When Windows throws STATUS_WMI_READ_ONLY (0XC00002C6), it's telling you: "Hey, this WMI data item or block is read-only. I can't write to it." This usually happens when you run a PowerShell script, a VB script, or some management tool that tries to change a WMI property that's marked as read-only. It's not your fault — the script probably assumed it could write to everything.

The quick fix

The simplest fix: stop trying to write to that specific WMI class or property. Find a different way to do what you want. But if you need to keep the script, here's the step-by-step.

Identify which WMI class the script is trying to write to. Look at the error message. If it says something like "Win32_Service.Change" or "Win32_Process.Create", that's your target. Those are standard read-only classes in most cases.
Check if the class supports the operation. Run this in PowerShell as admin:
```
Get-WmiObject -Class Win32_Service -List | Select-Object Name, Methods
```
If the method isn't listed, you can't use it.
Use the correct WMI method or class. For example, instead of trying to set a property directly on Win32_NetworkAdapter (which is read-only for IPv4 settings), use Win32_NetworkAdapterConfiguration's EnableStatic() method. That one is writable.
If you wrote the script yourself, change the approach: Use Invoke-WmiMethod in PowerShell or IWbemServices::ExecMethod in C++/C#. The error happens because you tried Put on a read-only object, not because you used the wrong method.
Test with a different WMI namespace. Some custom WMI providers mark their entire namespace as read-only. Try root/cimv2 instead of a vendor-specific one like root/HP or root/Dell.

Why this fix works

Here's what's actually happening. WMI has two kinds of objects: instance objects (like a specific service) and class objects (the template). When you call Put on an instance object, you're trying to update its properties. But many WMI providers mark those properties as read-only — especially for hardware or system configuration items. The error WBEM_E_READ_ONLY (0xC00002C6) is WMI's way of saying "I see you want to write, but this thing doesn't allow writes."

The reason step 3 works is that WMI methods like EnableStatic() are designed to accept input parameters. They're wrappers around actual system calls (like Windows API functions). The script sends data through the method, not through a property set. The provider then does the write internally, bypassing the read-only flag.

Another thing: if you're using an older tool or script that calls SWbemObject.Put_ directly, it'll fail on read-only items. The fix is to switch to SWbemServices.ExecMethod. That's the correct API for calling WMI methods, not for setting properties.

Less common variations of the same issue

Sometimes the error shows up in unexpected places:

Custom WMI providers from third-party software — like antivirus, backup tools, or hardware monitors. They often create read-only classes. If you see this error in a vendor-specific namespace, contact the vendor. You can't fix it yourself.
WMI repository corruption — if the repository gets corrupted, a previously writable class can become read-only. Run winmgmt /verifyrepository to check, and winmgmt /salvagerepository to fix if needed.
Permissions issue — the error code 0xC00002C6 is specific to read-only, but sometimes a permissions problem creates a similar error. Check if your account has Enable Account and Remote Enable rights on the WMI namespace. Use wmimgmt.msc to verify.
Windows 10 2004 and later — Microsoft changed how some WMI classes work in newer builds. For example, Win32_NetworkAdapter's SetPowerState method became read-only in some versions. Check your OS build.

How to prevent this from happening again

Three things you can do to avoid this error:

Always check WMI documentation — before writing a script, look up the class on Microsoft's WMI docs. It tells you which properties are read-only and which methods exist.
Use PowerShell cmdlets instead of raw WMI calls — Set-Service, Set-NetIPAddress, etc. These handle the write operations correctly. They're wrappers that call the right WMI methods under the hood.
Test on a non-production machine first — run your script against a test VM. If you see 0xC00002C6, you'll know before it hits your production servers.

One final tip: if you're absolutely stuck and the script is critical, try running it as SYSTEM using psexec -s. Some WMI providers behave differently under SYSTEM context. But that's a hack, not a real fix.