There might be a problem where Windows 10 doesn't actually scan stuff (partition table entries) during boot and relies on some sort of cached information.
Situation I ran into:
Windows 10 + Linux (Fedora 31) dual boot off of NVME ssd.
Everything good.
I added a fully zeroed (with dd) secondary internal hard drive (/dev/sda).
I booted into Windows 10 with it plugged in - of course shows up as uninitialized.
I then booted into Linux, created a Dos MBR on it, and a primary NTFS partition (/dev/sda1, type 7), ntfs-3g mounted it in linux, copied files to it, made it automount via /etc/fstab.
Everything was fine under Linux, but Windows continued to claim the disk was uninitialized.
(eventually I threw up my hands in frustration and:)
In Windows 'Disk Management' I told it to initialize the disk with a new MBR.
(Linux now refused to boot, since it couldn't find /dev/sda1 to mount... queue Linux recovery...)
In Linux I recreated the NTFS partition in the MBR with the same start/end sectors, and no wipe. Linux happy again. Copied files still there.
In Windows I could still see only a freshly initialized disk.
(more head scratching...)
Using Windows 'Disk Management' to offline and then online the disk made the partition show up as D: and it has all the copied files. Scanning it for errors find no problems, although curiously it appears to be in massive need of defragmenting (even though there was only a bunch of stuff copied to it, nothing was ever deleted) - defragmentation successful.
I would thus claim that Windows has some sort of partition cache that doesn't get updated without manually offlining/onlining internal hard drives...
This is presumably even more problematic for the primary drive, which you presumably can't even offline due to it being the boot/C: drive.
As such for the primary windows boot drive, probably don't muck with stuff from outside of the 'Disk Management' utility.