Inexisting partition in disk defrag

[NormanCyprien]

Hello, the other day I tried to defragment my external HDD with the default disk defrag from Windows 7 and after closing the program, unpluging the drive and reopening the program, I've got a "ghost" partition in the program. It doesn't have proper drive letter (it is shown as \\?\Volume{a long chain of caracters}\) and this "ghost" partiton isn't shown in the drive manager (the utility that shows your drives and your parttions). I restarted the computer multiple times and checked my drive with my installation of Windows with CHKDSK.

So, is there any option to remove a partition from the disk defragmenter ?

[jaclaz]

In disk manager a small volume is often difficult to see, there is an option to represent the disk partitions all the same length as bars, independent from their size.

What you are seeing is probably a volume to which a drive letter has not been assigned (this may be "normal" or an issue of some kind).

You can run (in a cmd window) mountvol to check which letters are assigned to which volumes.

As well, from command line, diskpart will be able to show you where (to which disk it belongs) that volume.

jaclaz

 

[NormanCyprien]

Thanks for the reply. I checked disk manager but my external HDD doesn't appears (since it is not connected to my computer). When I check mountvol, I see 5 partitions: my system partition, my DVD drive, my SD card reader and  2 hidden partition (the first allows my computer to boot and the second is a re-install partition) so no traces onece again of my external HDD. However, something is off, ALL my volumes have got the same UNC name. I also checked diskpart but this time, everything looks OK. I've got 2 drives (my internal SSD and my SD card reader) and the first drive contains my system partition and the two other partitions I've already talked about. 

This "ghost" partition only appears on the disk defrag utility. It is absent of every other place in the system. Any ideas about how to remove it ?

[jaclaz]

Sure, but you need to check at a time where your external HD is connected.

It is "queer" that a volume or partition remains "sticky" in the defrag tool (because it actually exists or existed on the external hard disk) even once the external hard disk has been disconnected, but surely it would be much more "queer" if this volume or partition never existed.

I don't know, but maybe it could be connected to the "Schedule" settings of the defrag tool, I would expect that in some cases it can happen that a volume is scheduled for a periodical defrag (at a time when it is  connected) and *somehow* the item remains sticky.

Check this thread here, ignore the first reply, open other replies and go to page 2, look for the reply by MikhoulLhaboul

https://answers.microsoft.com/en-us/windows/forum/all/strange-volume-listed-by-disk-defrag/00ea7a77-12b7-450b-a6b7-94dae520bcdd

he suggests something similar.

You may want to try toggling disk defragmenter schedule on and off.

jaclaz

 

[NormanCyprien]

After a little investigation, the "sticky" partition is not my external HDD. The other day I bought a Samsung external SSD and try to defragment it to see if it was fragmented. My external HDD disapears when I unplug it so this "ghost" partition is my external SSD and since this bug happened at arround the time I bough this new SSD , I think this is partition is actually my external SSD. This is weird because if I try to re-do the bug in a Virtual Machine running Windows 7, the external SSD isn't listed as a disk that can be defragmented and if I try to defragment it with Windows 10, this time the external SSD is listed but grayed since you can't defragment an SSD (because it is useless and even bad for the disk). So it looks like the disk defragmenter didn't understood that the disk I pluged was an external SSD (it must have thought that I installed a second SSD into my PC and later refused to remove it from the list).

Edited March 4, 2023 by NormanCyprien

[NormanCyprien]

Also, I tried to toggle disk defragmenter schedule on and off but that didn't do anyhting. Also, "MikhoulLhaboul" is running Windows 10 from what I can see and I'm running Windows 7 and when I go to "select disks" in of the "schedule" part of the disk defragmenter, I've two option: "Select all the drives" and "Automatically defragment new drives"(I can't select only one partition)

Then, when I look at the registry, I don't have the folder S-1-5-21-3633204063-1869434021-143583576-1001 but S-1-5-21-3956755495-4222808907-3415648961-1000 and finaly, when I found the folder that contains all the partitions, my "ghost" partition isn't here. I've got (according to the UNC names that I was able to find in "diskpart" and "mountvol"), on C drive my my main partiition, my boot partition and my restore partition and also my SD-Card reader and my DVD Drive.

[jaclaz]

14 minutes ago, NormanCyprien said:

 I'm running Windows 7 and when I go to "select disks" in of the "schedule" part of the disk defragmenter, I've two option: "Select all the drives" and "Automatically defragment new drives"(I can't select only one partition)

Strange:

https://www.wikihow.com/Defrag-Windows-7

I am not sure I understand what you mean by "UNC names"?

Mountvol shows GUIDs, diskpart (AFAICR) shows neither UNC nor GUID.

 

jaclaz

[NormanCyprien]

3 hours ago, jaclaz said:

Strange:

https://www.wikihow.com/Defrag-Windows-7

 

[NormanCyprien]

3 hours ago, jaclaz said:

I am not sure I understand what you mean by "UNC names"?

Mountvol shows GUIDs, diskpart (AFAICR) shows neither UNC nor GUID.

Well, I must be wrong. When I type "mountvol", I've 5 partitions showing under names like \\?\Volume{XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\ and under this, I've got their names with letter (C:\ - D:\ - F:\ ...). I thought that this long chain of characters was the UNC name of a drive.

 

3 hours ago, NormanCyprien said:

(according to the UNC names that I was able to find in "diskpart" and "mountvol"

What I mean here is that using "diskpart" "mountvol" and the "drive manager", I managed to link and confirm that this chain of characters was this partition and this other one this other partition etc... for all my partitions and drives. And as I already saied, no traces of any "ghost" partition in any of thoses programs and it is neither in the folder of the registry that "MikhoulLhaboul" mentioned.

[NormanCyprien]

20 minutes ago, NormanCyprien said:

What I mean here is that using "diskpart" "mountvol" and the "drive manager", I managed to link and confirm that this chain of characters was this partition and this other one this other partition etc... for all my partitions and drives. And as I already saied, no traces of any "ghost" partition in any of thoses programs and it is neither in the folder of the registry that "MikhoulLhaboul" mentioned.

I tried to clarify everything with this little drawing. As you can see, there isn't any ghost partition.

[jaclaz]

Yep, those are volume GUID's.

It is very common to fail to communicate properly because the terminology is very confusing.

You have a single disk (hard disk or SSD)  with three primary partitions in it (that are also three volumes, of which only one has a drive letter assigned, C: ), which is a "fixed" device.

The D: drive letter is assigned to the CD (or DVD) drive. (removable, with no media inserted)

The F: drive letter is assigned to some other device (SD or CF card reader). (removable, with no media inserted)

In mountvol you have 5 entries (3+1+1=5), each with its own GUID (differing only on the 8th character, 5/6/7/f/a).

Everything seems "normal" (exception made for the "some other device" that would normally get drive letter E:, but the assignment to F: could have been made manually or - possibly - during setup at a certain stage the E: was taken and thus the following F: was used for it).

The GUIDs are compatible with a system installed around 15:24 of the 25th of May 2022.

SInce you have only one drive letter assigned to a defragmentable volume, probably you have that "all disks" item in the defrag tool, but cannot say for sure.

You can check yourself the GUIDs (also that of the "ghost" volume) using the uuid tool (use the -d switch to decode the GUID):

https://soft.rubypdf.com/software/guidgen-ossp-uuid

Then, you could check your registry in HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices to see if the "ghost" drive GUID is listed in there.

jaclaz

 

Edited March 4, 2023 by jaclaz

[NormanCyprien]

3 hours ago, jaclaz said:

You have a single disk (hard disk or SSD)  with three primary partitions in it (that are also three volumes, of which only one has a drive letter assigned, C: ), which is a "fixed" device.

The D: drive letter is assigned to the CD (or DVD) drive. (removable, with no media inserted)

The F: drive letter is assigned to some other device (SD or CF card reader). (removable, with no media inserted)

In mountvol you have 5 entries (3+1+1=5), each with its own GUID (differing only on the 8th character, 5/6/7/f/a).

Yeah, that is what I was trying to say.

 

3 hours ago, jaclaz said:

Everything seems "normal" (exception made for the "some other device" that would normally get drive letter E:, but the assignment to F: could have been made manually or - possibly - during setup at a certain stage the E: was taken and thus the following F: was used for it).

Once again, everything is normal here (I alway had is E:\ - F:\ drive "issue", I know how to change the drive letter but maybe there is a good reason for why this is like this so I don't want to change it)

 

3 hours ago, jaclaz said:

The GUIDs are compatible with a system installed around 15:24 of the 25th of May 2022.

How do you know that ?

3 hours ago, jaclaz said:

Then, you could check your registry in HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices to see if the "ghost" drive GUID is listed in there.

 

Even before using that "uuid tool", there are 28 entries in this "folder" of the registry

Edited March 4, 2023 by NormanCyprien

[jaclaz]

On 3/4/2023 at 10:32 PM, NormanCyprien said:

How do you know that ?

Even before using that "uuid tool", there are 28 entries in this "folder" of the registry

The GUID's are uuid's Version 1, even if they appear "random" numbers they encode the date/time when they were generated and the MAC address of the machine on which they were generated.

The linked uuid tool can decode them.

Since they are generated the first time a volume is detected by the OS, when (as it is in your case) they are all within a few seconds it means that there were no "later additions" of devices or resets/modifications/etc.

Decoding the GUID of your ghost volume could give you the date when it was connected first time.

The Mounted devices hive contains two kind of key names:

1) beginning with \DosDevices\ followed by a drive letter and colon

2) beginning with \\?\Volume followed by a GUID

The content of each key are (in the case of fixed media) the disk signature+the offset to the partition/volume, in case of removable media the "STORAGE path" to the device.

In practice the hive contains a (partial) "history" of volumes connected to the machine, as the contents remain "sticky" in the hive until they are overwritten/updated by some other volume mounted.

It is possible to either delete all entries but the ones related to the volumes you actually have or delete completely the contents and let the system rebuild them, but in your case, if there are entries related to the "ghost" volume, I would try deleting just those, as it is possible that for *whatever* reasons the defrag tool reads the "ghost" volume from that hive.

The other place where some volume info is stored is the (in theory related to Explorer) Mountpoints2 in HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2, though it is less likely to be the source for that "ghost" drive.

I would make a search through all the Registry for the GUID of that ghost drive (without the curly brackets) as the data may be in some other places, depending on how it was originally connected.

jaclaz

Edited March 12, 2023 by jaclaz
fixed typo

[NormanCyprien]

6 hours ago, jaclaz said:

The GUID's are uuid's Version 1, even if they appear "random" numbers they encode the date/time when they were generated and the MAC address of the machine on which they were generated.

In practice the hive contains a (partial) "history" of volumes connected to the machine, as the contents remain "sticky" in the hive until they are overwritten/updated by some other volume mounted.

It is possible to either delete all entries but the ones related to the volumes you actually have or delete completely the contents and let the system rebuild them, but in your case, if there are entries related to the "ghost" volume, I would try deleting just those, as it is possible that for *whatever* reasons the defrag tool reads the "ghost" volume from that hive.

The other place where some volume info is stored is the (in theory related to Explorer) Mountpoints2 in HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2, though it is less likely to be the source for that "ghost" drive.

I would make a search through all the Registry for the GUID of that ghost drive (without the curly brackets) as the data may be in some other places, depending on how it was originally connected.

That's very interesting, thanks a lot I think this will fix the problem. Unfortunately, my charger just caught fire so I won't be able to charge my PC for a few days. I will probable try this method friday or saturday.

PS: I will also try this in a VM so, I will see if this solution works.

[jaclaz]

Yep, I think there is no hurry, it doesn't seem to me as a "serious" issue, whatever it is the cause, it should affect only the defrag tool, that you surely don't use very often.

The charger catching fire seems like a much bigger problem, did it actually get flames/sparks (rare, dangerous) or did it only let out the magic smoke (common, usually harmless)?

https://en.wikipedia.org/wiki/Magic_smoke

jaclaz