Windows 10: Partition/Volume on HDD 'flagged' as removable drive

The single (MBR) HDD in this machine is partitioned for OS (dual boot) and data (multiple). I noticed in the context menu that the partition used to store software install packages has a Open Autoplay pick whereas the OS and Data partitions do not (as expected).




The 10 Boot (C: ) and 10 Data (D: ) partitions were created during/after a clean install of 10.1607.
The 05 swSetup (F: ) partition was created with 8.9600.

This really shouldn't matter, but it might be part and parcel of the other issues reported on drives marked raw or unallocated (not the case here though).




This doesn't seem to cause any issues, it's just odd to offer a Autoplay menu pick for a partition on the same internal HDD as the OS. I'll dig around a little to try an determine why Version 1607 (OS build 14393.187) thinks the partition is a removable drive, but I think this falls into Microsoft's domain to fix. I don't know when this oddity first appeared, I just happened to notice it when I went to run Defender on the drive for a routine scan (no malware suspected or found in the scan).

If anyone has a HDD with partitions on a drive that were created in Win8.1 being accessed by Win10.1607, could you check if your machine presents the Open Autoplay context menu pick for that partition?

Thanks.

Yes, I know the OS is on a logical drive, I've been running my systems this way for a long time. Only the SR has to be on a Primary partition, the rest can be Logical.

:)

 

Event Log Error 441 - failer to migrate HDD during install

I have same problem - new WD disk drive, "working properly" in device manager, not appearing in disk management with event message "not migrated" in Windows 10.

I solved the problem by :-

1. Remove the HDD from the desktop and load the hard disk into an USB HDD external box

2. Plug USB into a laptop running an old version of Windows (pre Windows 8)

3. The drive showed up on disk management - delete the complete volume.

4. Disk management then allows you to create new partition and the wizard allows you to assign a drive letter. I don't suggest formatting a large partition at this point as you will be there for hours!

5. Reinstall the HDD into the desktop and run disk management - the drive now appears and you can create partitions and format etc. as normal.

This only works for a new drive with no data on it - these steps will completely wipe anything on the HDD.

Hope it helps

 

Lost OS after update - primary disk locked (SOLVED)

I installed Windows to a USB thumb drive. It's a real hassle, but you'll need 20GB if you're going Windows 10 Pro. Even on USB 3, it's painfully slow. I did some poking around: something assigned a drive letter to my system reserved partition and flagged
my primary disk read-only. Through the use of the diskpart utility I cleared the read-only flag. Then in disk management I removed the drive letter to the system reserved partition. For what will be your primary partition, be sure to mark it as active, since
that flag was probably reset too. Shutdown Windows, remove USB, reboot. Boot sector had errors, inserted installation media to repair startup... At reboot, remove installation media, choose your OS if applicable... Problem solved.

 

It's nothing unusual about this.
If you have a "autorun.inf" file in the root of this drive then you would have this option.

 

I just copied an autorun.inf to D partition (which is on my internal SSD) and didn't get this option, whereas for my external USB I get it on all partitions with or without an autoplay.inf

 

On my windows 7 my shared formatted ntfs partition has an open autoplay option but no autorun.inf file. The windows 7 partition itself doesn't have an open autoplay option.

 

Great thought, but ... no autorun.inf on the partition

Thanks for testing Dino's suggestion and for checking the external drives with/without autorun.inf

 

Thanks - I think that confirms that there is an issue and that it is not just an anomaly on my machine. To reiterate, this doesn't cause any operational issues of which I'm aware

What Win10 build are your running - just curious if a different build also exhibits the issue.
- I'm up to date on Version 1607 (OS build 14393.187)

The key seems to be non-OS partitions (your post made the distinction) created with previous versions of Windows that are accessed by a Win10 install.

+edit
I just added a drive letter to my Win8 boot part and it DOES have the Open Autoplay pick. So at least on my machine there is no distinction between an OS part or a non-OS part.edit

 

In addition, you must have the Autoplay option turned on. If you prefer not to have the option then use Group Policy:

• Under Computer Configuration->Administrative Templates->Windows Components, click Autoplay Policies.
• In the Details pane, double-click Turn off Autoplay.
• Click Enabled, and then select All drives in the Turn off Autoplay box to disable Autorun on all drives.

 

Thanks Dino, that worked.

I'll feed MS the information since I don't think it is normal behavior. Also note that I routinely deselect Autoplay when I install Windows and it was not selected in Cpl Autoplay options before making the policy change.

Bill
.

 

I am unfortunately not using windows 10 anymore do to an issue thats irritating. That doesn't mean I don't like 10, I do like 10. Windows 10 no longer works with my system.

Here is my partition setup

Windows 7 Primary Partition 1
Ntfs Shared Primary Partition 2
Linux Swap Logical Partition 5
Ext 3 Empty Logical Partition 6
Linux Mint 18 Logical Partition 7
Ext 3 Empty Logical Partition 8

 

Thanks for the clarification groze,

The two things thing I see in common are

• Multi-boot
• Shared partition

I had Mint as one of the boot options, but have since clean installed both Win8 and Win10 ... so I'll rule that out as a possible cause for now.

We also differ on the OS partition - you're install does not offer the option, but I do get the option on the Win8 partition.

I'll eventually clean install again, so I can live with the workaround TopGun provided in post# 7.