4

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:

Improve this question

2 Answers 2

Reset to default
6

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

Improve this answer
9
  • Impressive. How did you figure this out?
    – Jon
    Commented Mar 17, 2016 at 6:24
  • 1
    I have been testing and fliping through information about NTFS (metadata, metafile...), and couldn't find anything really seems like it. And then I thought I should test with FAT32 and see if things behave differently and they didn't. So I figure this is probably related to some hidden system file, which could be found on both types of filesystems.
    – Tom Yan
    Commented Mar 17, 2016 at 6:42
  • Ok, will verify that's the case when I get back to my PC so I can accept your answer. So FAT32 doesn't have an equivalent to NTFS's "volume unique identifier"? It still seems like a design flaw - ie, it should use the NTFS feature when it's there, otherwise fail back to a hidden system file GUID. Btw deleting it seems do-able by taking ownership and changing security permissions.
    – Jon
    Commented Mar 17, 2016 at 6:47
  • volume unique id (mountvol X: /L) has nothing to do with the filesystem, but only the partition (table). For GPT disk, Windows use the unique partition GUID as the volume unique id. For MBR disk, it make use of the disk identifier (uniqueid in diskpart) and the starting position of the partition to form the volume unique id. Both FAT32 and NTFS have volume serial; it's just the one of NTFS is technically longer (fsutil fsinfo ntfsinfo X:, but if you check with dir X: only part of the NTFS serial is shown, probably for compatibility with the shorter FAT32 serial).
    – Tom Yan
    Commented Mar 17, 2016 at 7:12
  • Somehow Microsoft prefer not to use any of the serial / IDs for its indexer, but randomly generate another one and store it in a hidden system file (if not already exists) when the volume is mounted. I am not sure if it can be called a design flaw though. It's just Microsoft doesn't seem to consider "cloning" an orthodox thing to do. (But well, at least Windows regenerates those GUIDs on the partition table for you.)
    – Tom Yan
    Commented Mar 17, 2016 at 7:14
1

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.

Improve this answer
3
  • 3
    How did you delete the GUID from Windows cmd? What command did you use? The accepted answer says they don't know how and your's says that you were able to do it by running cmd as Administrator... What command did you use exactly?
    – lx07
    Commented Jan 7, 2020 at 18:53
  • 1
    Download sysinternals (docs.microsoft.com/en-us/sysinternals) and run psexec -s cmd.exe from an Administrator command prompt, which will open another command prompt with SYSTEM account privileges.
    – zencraft
    Commented May 14, 2021 at 2:46
  • Sorry completely missed this question (came back here because I'm cloning to another NVME drive and now got the fun of GPT boot managers but anyway...) for the record I simply used the command line "del filename" to delete the file! I didn't need to be logged in with the system account but that would work too as per zencraft's comment.
    – choddo
    Commented Apr 27, 2023 at 10:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .