Windows 11 All 22H2 Builds explorer.exe Previous Versions / Shadowcopy broken for local drives, NtFsControlFile failed error 1450 ntdll.dll/kernel32.dll

Question

First noticed with 22621.105, and then tested with all builds up to 22621.436: Explorer "Previous Versions" tab shows no previous versions for local drives:

But when checking with vssadmin I see that those shadowcopys are there ! They are just inaccessible.

Using my own tool from https://github.com/Joachim-Otahal/Windows-ShadowCopy I can see which exact call failed, it is NtFsControlFile with Error 1450. This is the same call explorer.exe uses.

Can this be checked please?

I reported each time to insider feedback:

The feedback hub links are (chronological):

https://aka.ms/AAhhfuw 22621.105 where I first noticed the problem
https://aka.ms/AAhh88j 22621.160
https://aka.ms/AAhhlr7 22621.169
https://aka.ms/AAhhlr5 22621.290
https://aka.ms/AAhiia4 22621.436

I reported to https://answers.microsoft.com/en-us/insider/forum/all/windows-11-22621-shadowcopy-previous-versions/3df7b9e4-2aca-4ac1-85b3-0fd9a631781f and so on, until I finally got redirected to this place here. I hope someone ar Microsoft finally notices the problem and fixes it with the next update, or at least before it is rolled out to public.

I will switch back to 22000.795 now, 'cause I rely HEAVILY on ShadowCopy on top of my regular normal backups.

kind regards,

Joachim Otahal

Answer 1

Update again:

EVERY Windows 11 22H2 computer I had my hands on exposes this problem. Here screenshots from a work computer, a client pc of a "loves to be far ahead" user, who is technically capable to handle problems on his own instead of asking for support, already running Windows 11 22H2 while >99% of the company is still running Windows 10.

Answer 2

Windows 11 22H2, build 22623.1020, fresh installed VM, still the same issue. Though the error code seems to have changed, might be different for all 22623 builds compared to 22621 builds.

Answer 3

A little update on this: The most recent insider build, probably future 23H2 build, does not have this bug. So since 21H2 and 23H2 don't have this problem it should be easy for Microsoft to fix this for 22H2... At least I hope I don't have to delay my upgrade from 21H2 until the end of 2023.

Answer 4

Build 22623.1095: Bug is still there. Will be interesting whether my prediction "will be fixed in February" will become reality, or whether Microsoft won't fix this ever for 22H2 since the upcoming 23H2 build is already fixed. Screenshot from a vanilla Windows 11 VM.

Answer 5

Still not fixed, but right now "Feature update to 22H2" was offered as a normal and only update, and not just as optional.

This is not nice to push a Windows version with so many open bugs, including this one. Especially when it still includes bugs which are already fixed for the upcoming 23H2 builds, like the current 25284 build.

Have to resort to Group Policy, for the first time since Windows 7, to block an upgrade. Up to now all upgrades, including 8.0, 8.1 and all Windows 10 Versions from 1511 on were fine. This is the first time I am forced to block due to known bugs.