does anyone have any idea about this? There is a single recovery partition, however there are 2 recovery volumes. You can take a look on your cmd or powershell, as admin type: diskpart select disk 0 list partition list volume exit
Legacy, I was looking at the screens again and noticed you guys have it installed with (U)EFI, my bad!
It seems logic. Actually there is only one, but it appears as two. As I remember, I did the clean install two times, and for the second time, I did see only one recovery partition when I formatted and deleted every partition.
Did a clean disk in Diskpart (Deleted everything on disk 0), and after Windows install, it shows 2 recovery volumes. This didn't happen on previous windows build.
whats going on with this two OEM partitions ? This happening when install on EFI and also the one of both partition show as NTFS .
Oops.. I don't know that. But the Windows seems to be working fine. Will it get fixed by any CU update in the future?
Actually, there's still another method: By completely blocking Cortana. This will block web searches in start menu as well: Code: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Search] "BingSearchEnabled"=dword:00000000 "CortanaConsent"=dword:00000000 The downside to this is you have to repeat this for every user.
I have the same deal with 2 499mb partitions showing up, but my efi partition is 99mb, I see some people have a 100mb efi partition, how does windows determine what size to create during initial setup?
Don't count on a refresh esd soon, did you ever see one being released so soon after rtm (this one isn't even officially released)?
The double Recovery thing appears to simply be a minor "visual" bug in some areas of the OS. Looks like the Disk Management Console and DiskPart via CMD are the main ones. As others have called out, they are listing the Recovery Partition as two volumes. Technically, there is just one (aka nothing to really worry about), but visually you are seeing two volumes. Also, the Recovery partition type is being mislabled as an OEM Partition in the Disk Management Console too. With that being said, you can verify things by manually adding another Recovery Partition (GPT Type de94bba4-06d1-4d40-a16a-bfd50179d6ac) which causes the bug to occur yet again on reboot (aka it will now show 4). Hitting up WMI (via PowerShell or WMIC) or using the newer storage cmdlets in PowerShell do not have this problem at all. This leads me to believe this is a minor bug isolated to the Disk Management Console and DiskPart.