2

I cloned a Windows 10 HDD to a Samsung SSD using "Samsung Data Migration Software". I 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, hit OK, then hit 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: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex\DefaultRules\12] "URL"="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:

https://social.technet.microsoft.com/Forums/office/en-US/5381142e-12aa-47da-bae2-18e6d35f414f/issue-with-indexing-in-windows-confusing-c-disk-with-d-disk-need-to-change-sid?forum=w8itproinstall

https://social.technet.microsoft.com/Forums/en-US/bd2b31ea-4bf4-4271-886c-47131cc1b6c8/why-does-the-search-indexer-in-windows-10-insist-on-indexing-the-wrong-partition?forum=win10itprogeneral

https://social.technet.microsoft.com/Forums/en-US/ba7da25d-5754-42ee-a55e-c4b38d27f2fd/i-have-a-problem-with-windows-10-search-indexing?forum=win10itprogeneral

http://answers.microsoft.com/en-us/windows/forum/windows_10-win_cortana/windows-10-indexing-selects-wrong-drive/685ec87b-e7f3-454b-89c9-c485b94bb69d

http://answers.microsoft.com/en-us/windows/forum/windows_10-files/windows-10-indexing-problem/6aea5879-6d13-4a67-b30a-ab255a92ee0c

4

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

  • Impressive. How did you figure this out? – Jon Mar 17 '16 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 Mar 17 '16 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 Mar 17 '16 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 Mar 17 '16 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 Mar 17 '16 at 7:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.