Unable to delete shadow copies - Access Denied error

Question

Our backup system is failing because it's unable to delete previous shadow copies. This was working fine for 3 months. Now we are failing constantly. It's related to not being able to delete volume shadow copies. Here are the command line results from the processes we tried. Any constructive suggestions are appreciated. <n/b: the only VSS providers are from Microsoft in Windows Server 2019 Standard>

---

C:\Windows\system32>vssadmin delete shadows /all

Access is denied.

C:\Windows\system32>diskshadow

Microsoft DiskShadow version 1.0

Copyright (C) 2013 Microsoft Corporation

On computer: MVO-MAIL2, 12/11/2025 8:36:14 AM

DISKSHADOW> delete shadows all

COM call L"lvssObject->Query" failed.

The last operation failed.

    - Returned HRESULT: 8004230f

    - Error text: VSS_E_UNEXPECTED_PROVIDER_ERROR

DISKSHADOW>

---

Answer 1

Hi Bill Artemik,

The error VSS_E_UNEXPECTED_PROVIDER_ERROR (0x8004230f) combined with "Access is denied" is a strong indicator that the Microsoft Software Shadow Copy Provider service is in a "zombie" or hung state. Even though you are running as Administrator, the service is refusing the deletion request because it cannot process the internal logic required to access the shadow storage area.

Here is the procedure to clear this deadlock:

Step 1: Force Restart the VSS Services

• Open an elevated Command Prompt (Run as Administrator). Run the following commands in order to stop the services (don't worry if it says they aren't started):

net stop "Microsoft Software Shadow Copy Provider"

net stop "Volume Shadow Copy"

• Now, start them back up:

net start "Microsoft Software Shadow Copy Provider"

net start "Volume Shadow Copy"

• Try your deletion command again:

vssadmin delete shadows /all

Step 2: The "Resize" Trick (If Step 1 fails)

If the deletion still says "Access Denied," the Shadow Storage area itself might be corrupted or locked. We can force VSS to "re-evaluate" the storage area by slightly changing its size limit. This often breaks the lock on old files.

• Check your current association (replace C: with your target drive letter):

vssadmin list shadowstorage

Note the "Maximum Shadow Copy Storage space" value.

• Resize it to something infinite (UNBOUNDED) or slightly larger/smaller to toggle the state:

vssadmin resize shadowstorage /for=C: /on=C: /maxsize=UNBOUNDED

• Immediately try deleting the shadows again:

vssadmin delete shadows /all

Step 3: Check for "Ghost" Providers (Critical)

You said that "the only VSS providers are from Microsoft," but often backup software updates (like Veeam, Datto, or Azure Backup) can leave a corrupted registry key that hides a third-party provider, causing the System Provider to fail with 0x8004230f.

• Open Regedit. Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Providers
• You should see only one subkey here: {b5946137-7b9f-4925-af80-51abd60b20d5} (This is the Microsoft Software Shadow Copy Provider).
• If you see any other GUIDs below it, export the key for backup, and then delete the extra GUID keys. Restart the services again (Step 1) and retry.

One final note on "Access Denied": If vssadmin delete shadows /all continues to say "Access is denied" despite being Administrator, it is possible the shadows were created by a specific Backup Service Account (e.g., Azure Backup or SQL Backup) that has set a "Hardware" flag or "Backup" flag on the shadow that prevents manual deletion. In that case, diskshadow is usually the answer, but since your diskshadow is erroring out, Step 1 (Service Restart) is your highest probability fix.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept answer. Should you have more questions, feel free to leave a message. Have a nice day!

VPHAN

Answer 2

Hi there,

I'm writing to follow up the issue, whether it has been resolved or not. Since the VSS_E_UNEXPECTED_PROVIDER_ERROR (0x8004230f) is notoriously stubborn on Windows Server 2019, I wanted to provide a deeper level of analysis in case the initial service restart did not clear the lock. If the previous steps failed, it is highly probable that a specific VSS Writer is in a failed state and is effectively holding the Provider hostage, or there is a deeper corruption in the COM registration of the VSS subsystem.

You should immediately run the command vssadmin list writers in an elevated prompt. The Provider error you are seeing often masks the real issue: a writer like the "System Writer" or "WMI Writer" sitting in a [9] Failed or [8] Failed state. If you see the System Writer listed as "Timed Out" or "Waiting for Completion," simply restarting the Volume Shadow Copy service is insufficient because that writer is tied to the Cryptographic Services. You would need to restart the "Cryptographic Services" (cryptsvc) service to release the System Writer's handle on the file system. Similarly, if the "WMI Writer" is failed, you must restart the "Windows Management Instrumentation" service.

Furthermore, the "Access is denied" error during deletion is distinct from the Provider error. If you are running as Administrator and still getting denied, check if the System Volume Information folder on that drive has become corrupted or has incorrect ACLs. A quick way to test if the OS can write to its own shadow storage is to look at the Event Viewer under Windows Logs > Application. Filter for Source: VSS. If you see Event ID 12293 or 12298, it indicates that the VSS subsystem cannot allocate storage space on the physical disk, potentially due to fragmentation or a "ghost" volume ID in the BCD store.

If the writers are stable and the error persists, there is a known issue in Server 2019 where the VSS DLL registrations become orphaned after cumulative updates. You can re-register the core components by running a specific sequence of commands in an administrative prompt. Run regsvr32 /i swprv.dll, followed by regsvr32 /i eventcls.dll, and regsvr32 /i vssui.dll. After registering these, reboot the server. This forces Windows to rewrite the COM+ catalog entries for the Shadow Copy provider, which often resolves the 0x8004230f error when standard troubleshooting fails.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP