Windows is unable to detect disk partitions

First, ignore Windows' identification of your logical partitions as "primary;" that's a long-standing Windows bug.

Second, it's conceivable that the NTFS partition you created in Linux has the wrong partition type code. You can view the type codes using the Linux fdisk command, as in fdisk -l /dev/sda (typed as root or preceded by sudo). An NTFS partition should have a type code of 07 under the Id column in fdisk's output. If it doesn't have that code, you can change it with fdisk; type fdisk /dev/sda, then use the t option to change the type code and w to save your changes.

Another possibility that occurs to me is that the NTFS structures may be invalid. You could try converting the partition to FAT and see if it's visible then; and if it is, convert it back to NTFS in Windows. That might produce an NTFS that Windows would like.

The only other possibility that springs to mind is that this is a Windows bug -- namely, that it can't read a primary partition that comes after an extended partition. If so, the obvious (but awkward) solution is to delete the NTFS partition, use a Linux emergency disc and GParted to move your Linux partitions to the end of the disk, and to create a fresh primary NTFS partition that comes before the extended partition. Before you try this, though, I recommend you wait and investigate it some more; somebody else may come up with another (safer and easier) thing to try.

Whatever you do, though, do not try to create a new partition in Windows; the Windows partitioner has the annoying habit of converting disks to use LDM (aka "dynamic disks") whenever you want more than four partitions. Linux can't boot from such setups (or if it can, doing so is a very poorly documented), so if Windows were to do such a conversion you'd be in even deeper trouble. I don't know offhand if Windows would do this when the disk contains non-Windows partitions, and I don't think trying it on your disk is a good way to learn about this!

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.