Why does Windows Search "Indexing Options" select the wrong drive if it's cloned?

Question

I cloned a Windows 10 HDD to a Samsung SSD using "Samsung Data Migration Software", then installed a fresh copy of Windows 10 on the SSD. The SSD is now C: and the HDD is D:.

When in Control Panel > Indexing Options > Modify, any folder I add for C:\ actually selects D:\. For example, I'll select C:\Windows > OK > then Modify again and it's D:\Windows that's selected; or if I select a folder that doesn't exist in D:, such as C:\util, it adds an entry like D:\util\ (unavailable).

Something is confusing Windows Search and Indexing Options due to the cloned drives. When looking in the registry, I can see entries such as:

HKLM\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex\DefaultRules\12

• REG_SZ
  Name: URL
  Data: file:///C:\\[9a6b2440-0cb7-4d60-a957-7a1682cf61c4]\\WINDOWS\\

It might be the GUID after C:\\ that's confusing Indexing Options, but this GUID appears nowhere else in the registry other than under Windows Search. It's not the volume's unique identifier that can be seen using Mountvol, and it's not the GPT identifier (or the partition type) that can be seen using DiskPart.

Note: others have experienced the same issue (in Windows 8 as well), see:

• Issue with Indexing in Windows confusing C disk with D disk - need to change SID
• Why does the Search Indexer in Windows 10 insist on indexing the wrong partition?
• I have a problem with Windows 10 Search Indexing
• Windows 10 indexing selects wrong drive
• Windows 10 indexing problem

Answer 1

First of all I can reproduce your problem:

The problem is caused by the system file \System Volume Information\IndexerVolumeGuid in each of the cloned volumes. Apparently you are right about the fact that the system is confused by the GUID(s) you see in those the registry entries under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex\*, and this file should be the provider of the GUID(s).

Since the volumes are cloned, this particular file is identical among each of them just like other files. And it will NOT get "updated" (i.e. regenerated to avoid conflicts) when the volumes are mounted, just like the volume serial:

However, apparently this file is safe to be deleted, and once the volume is mounted again, a new one will be generated; the problem will be gone once ALL the volumes that owned a duplicated GUID are remounted with unique GUIDs (so a reboot may be necessary if it involves the current system volume):

Unfortunately, I am not sure if there's a convenient/safe way to delete it under Windows:

Answer 2

Just registered to say thanks for this, has been causing me problems for 18 months since I cloned a windows system drive onto an nvme using xxclone and kept the old drive around (without formatting) for data and backup purposes.

I was able to delete the GUID file from the old drive just by running cmd as Administrator, and I rebooted (may not have been necessary) - had to do a little clean up on the indexing folder options but once I'd completed that, the indexer started working again. Awesome.