Windows Search – Indexing Options Selecting Wrong Drive After Cloning

clonesearch-indexingwindows 10windows 8windows-search

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:

Best Answer

First of all I can reproduce your problem:

enter image description here

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:

enter image description here

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):

enter image description here

enter image description here

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

enter image description here