Inexisting partition in disk defrag

[NormanCyprien]

Something really wierd happened today. In the registry, I searched for all the possible places where my "ghost" partition could be. Actually, it's GUID was in some of the "folders" that you gave me the path to. So, I deleted them and rebooted. And gess what ? My "ghost" partition is still here BUT IT'S GUID CHANGED! Also, when I try to search it's GUID, the registry loads for about a minute and then says "Search completed" and doesn't display anything else even if theses values exists.

So it looks like the system thinks that the disk is still pluged in.

On 3/6/2023 at 10:34 AM, jaclaz said:

did it actually get flames/sparks (rare, dangerous) or did it only let out the magic smoke (common, usually harmless)?

Oh and also, no the charger didn't make any flames but it maded a short circuit sound and realeased smoke and a burned plastic smell.

[jaclaz]

Yep, it is strange.

By decoding the GUID/uuid, you should be able to confirm that this new GUID has been newly generated.

But if it was, it should be foundable at least in MountedDevices in the Registry, AFAIK the GUID is generated when the mount manager detects a device and then it is written in the MountedDevices, the theory - till now - was that the GUID was generated like that and then, even if the device was not anymore present, the value remained there (and possibly in a few other places in the Registry), but if a new GUID has been generated *something* must have triggered it (and it should appear in mountvol, unless it is again disconnected).

If it is, you can by the value determine either the disk signature or its Storage Path.

At least on XP (but 7 might behave the same) some keys/values may not be findable in Regedit, though it is admittedly a rare case you could try a third-party registry tool

Could it be connected to some Virtual Disk Driver? (besides "proper" virtual disk drivers that you may have intentionally installed, some CD/DVD burning tools sometimes install one).

jaclaz

 

 

Edited March 12, 2023 by jaclaz

[NormanCyprien]

On 3/12/2023 at 1:50 PM, jaclaz said:

By decoding the GUID/uuid, you should be able to confirm that this new GUID has been newly generated.

 

I don't need to do that. I listed all my GUIDs before and it wasn't here. Also, I didn't pluged any external media since so I'm sure that it has been generated when I deleted the old one and rebooted.

 

On 3/12/2023 at 1:50 PM, jaclaz said:

But if it was, it should be foundable at least in MountedDevices in the Registry

Yes, the GUID is present in "MountedDevices", but when I delete it (as well others key with that GUID) a new one is generated.

 

On 3/12/2023 at 1:50 PM, jaclaz said:

but if a new GUID has been generated *something* must have triggered it (and it should appear in mountvol, unless it is again disconnected).

That what I was saying, The defrag program must think that the drive is still pluged in but it can't find it. So, it creates a new GUID that is only displayed in that program and in some places of the registry.

 

On 3/12/2023 at 1:50 PM, jaclaz said:

you could try a third-party registry tool

I don't want to do that since third-party registry tools are often badly programed and may crash an entire install of Windows. Also, I can find the GUID in the registry if I know the correct "folder" but they don't appears when I do a search. It's not an issue, it just complicates things a bit.

 

On 3/12/2023 at 1:50 PM, jaclaz said:

Could it be connected to some Virtual Disk Driver? (besides "proper" virtual disk drivers that you may have intentionally installed, some CD/DVD burning tools sometimes install one).

Well, I've got 3 virtual hard drives created by VMware (two in IDE for a virtual Win98 and a virtual WinXP and one in NVMe for a virtual Win10). To open .ISOs, I use winrar and to burn/rip discs, I use CDBurnerXP-4.5.8.7128. I never installed virtual disk drivers except for VMware (but they installed by themselves) and I don't think that CDBurnerXP installs drivers. Also, I don't think the issue is caused by thoses programs since I use them on my two secondary computers (that are running XP and 7) and I've never got this issue. Also, this ghost partition appeared when I tried to defragment my SSD and in a previous install of Windows 7, I tried to defragment a USB key and the same problem happened (and since I reinstalled Windows later, I never really fixed this issue).

Edited March 20, 2023 by NormanCyprien

[jaclaz]

Hmmm, I don't know how/where else to look for the origin of that volume.

What are the contents of the key with that GUID in MountedDevices?

As said earlier, if it is not a hard disk volume it should contain some info on its storage path, usually leading to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\STORAGE

Some are "generic" RemovableMedia" or "Volume", others may lead to "USB", "USBSTOR", or to the name of a driver.

I would try using DriveCleanup (by Uwe Sieber):

https://www.uwe-sieber.de/drivetools_e.html

and see if the volume is listed among the ones that can be removed (using the -T parameter) and if it does, I would try clearing the devices (unless you have other devices that you want to keep, even if disconnected).

Maybe, even if removed this way it is recreated at reboot, which should mean that you have some driver or service running that recreates it.

Also running the (similar) DeviceCleanup tool may give some results, but cannot say, that one is more about Code 45 devices:

https://www.uwe-sieber.de/misc_tools.html#devicecleanup

jaclaz

 

Edited March 20, 2023 by jaclaz

[NormanCyprien]

On 3/20/2023 at 4:26 PM, jaclaz said:

What are the contents of the key with that GUID in MountedDevices?

 

The GUID is \\?\Volume{72c19bc3-c024-11ed-ad1e-806e6f6e6963}\

 

On 3/20/2023 at 4:26 PM, jaclaz said:

As said earlier, if it is not a hard disk volume it should contain some info on its storage path, usually leading to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\STORAGE

Some are "generic" RemovableMedia" or "Volume", others may lead to "USB", "USBSTOR", or to the name of a driver.

Unfortunately, nothing in this "folder" (no traces of this problematic GUID)

 

On 3/20/2023 at 4:26 PM, jaclaz said:

I would try using DriveCleanup (by Uwe Sieber):

https://www.uwe-sieber.de/drivetools_e.html

This looks complicated to use (I downloaded it and run it but I wasn't able to do anything sorry).

 

On 3/20/2023 at 4:26 PM, jaclaz said:

Also running the (similar) DeviceCleanup tool may give some results, but cannot say, that one is more about Code 45 devices:

https://www.uwe-sieber.de/misc_tools.html#devicecleanup

Even if it looked more interesting, it didn't resolved the issue. I launched the program and saw my Samsung external SSD, but it was listed as "disconnected" and when I deleted it and rebooted, the "ghost" GUID was still here. Since the SSD was listed as "disconnected", I don't think deleting the entry made a lot of changes unfortunately.

Edited April 18, 2023 by NormanCyprien

[jaclaz]

Yep, that GUID decodes to

uuid -d 72c19bc3-c024-11ed-ad1e-806e6f6e6963
encode: STR:     72c19bc3-c024-11ed-ad1e-806e6f6e6963
        SIV:     152537264095622615413589416556765276515
decode: variant: DCE 1.1, ISO/IEC 11578:1996
        version: 1 (time and node based)
        content: time:  2023-03-11 15:50:29.500000.3 UTC
                 clock: 11550 (usually random)
                 node:  [redacted]

so it definitely has been recreated when you originally posted about it.

But what are the contents of that key in the Registry under MountedDevices?

If in regedit you double click on the key it should open a pop-up window with a title *like* "Modify binary data" that may contain something readable, on the left side you will see the actual bytes hex values, on the right side how they render as ASCII, since the values in that section are usually Unicode you will see each letter separated by a dot, but it should be readable.

The drivecleanup tool is not particularly difficult to use.

You open a command prompt, navigate to where the porgram is, then you issue the command:

drivecleanup -t

and it will list all the devices it finds "orphaned".

If your "ghost device" is among them, you re-run it as:

drivecleanup

and it will cleanup the entries listed before.

According to the docs, it checks these Registry paths:

Quote

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\LocalMOF
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\Volume

so, if you cannot find your ghost device GUID in those, it won't do anything.

jaclaz

[NormanCyprien]

16 hours ago, jaclaz said:

But what are the contents of that key in the Registry under MountedDevices?

 

Well, 18 d7 4f 9f 00 00 d0 a7 6f 00 00 is displayed but when I click on it, a window appears and I have this 

 

 

16 hours ago, jaclaz said:

According to the docs, it checks these Registry paths:

Well, no traces of the GUID in:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt (the "folder" is empty)

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\LocalMOF (I don't even have this "folder")

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\Volume

 

However, the GUID is present in:

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices (as mentioned above)

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume

 

In, HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume, I have 3 keys:

I tried to copy the content of "DATA" and paste it in a notepad document but I wasn't able to do it. Also, I can't take a screenshot since the content of this key is very very long.

[NormanCyprien]

Hello, unfortunately I don't think I will be able to solve this issue. As you already suggested to me this is probably a driver issue. I installed Windows 7 on this PC with an official "Retail" edition from Microsoft wich means I only have universal and very basic drivers. I had to install some (like the graphic driver or the wifi driver) and I thouht that everything was OK. But when I looked at the restore cd that I made a few years ago (that contains the factory system that was installed when I bought my PC), I've seen that there are included drivers for the hard drive. I'm not going to install thoses drivers since I don't want to accidently brick my installation of Winows 7. I will live with this invalid entry in the defrag program (since this is not a very big issue).

 

Obviously if I'm wrong or if you find anything, please let me know.

[jaclaz]

Hi, I missed your last reply in April, sorry.

Anyway I don't really know what it could be.

The key in mounteddevices being 12 bytes long should mean it is a hard disk like device made of disk signature (4 bytes) + bytes before volume (8 bytes), but the data in it makes little sense (if I am correctly converting it).

The disk signature would be 18 d7 4f 9f (and this could well be)

The offset would be 00 00 d0 a7 6f 00 00 i.e. 0x00006FA7D000 that in decimal translates to 479,556,796,416 bytes, such an offset can only be on a large disk 500 GB or more, so, it could be pointing to some area of your disk 0, but if this is the case, the disk signature 18 d7 4f 9f should be the same as the one in your \DosDevices\C:, and you would have noticed it.

I think the origin of this will remain a mistery, I don't believe that it could be related to any kind of driver if not a virtual disk one or similar and definitely not graphic or audio, but also not the "standard" disk ones you are using.

jaclaz

 

[NormanCyprien]

On 5/25/2023 at 8:16 PM, jaclaz said:

such an offset can only be on a large disk 500 GB or more, so, it could be pointing to some area of your disk 0

My disk 0 is 500 gb (but appears as 475 gb) so, I don't think it's this one. However, my external SSD that caused this issue is 2 tb so, this value is probably linked to this external SSD by a way or another.

 

On 5/25/2023 at 8:16 PM, jaclaz said:

I don't believe that it could be related to any kind of driver if not a virtual disk one or similar and definitely not graphic or audio

What I meant here was that I nearly only use default microsoft drivers on this PC (except for a few thing like the graphic card or wifi) and since on the OEM installation that would come with my computer back in 2012 there was custom hard disk drivers made by Acer, I thought that maybe this computer's hard drive system wasn't 100% compatible with Windows 7 by default. (without a driver)

 

Also, my external SSD that caused this issue was a Samsung T7 SSD of 2tb (maybe there are knowns problems with this SSD and Windows 7).

[jaclaz]

That difference is likely the one between Gb and Gb:

https://en.wikipedia.org/wiki/Gibibyte#Multiple-byte_units

Disks sizes are usually calculated with the 1000 multiplier, while MS uses the "real" 1024 multiplier,  (roughly) a disk 500GB is seen as 465 Gib and a 512 GB as 475 GiB, the exact numbers depend on the specific disk.

jaclaz