A Kingston USB drive sits beside a laptop showing contrasting transfer speeds and Windows removal policy settings.
Slow USB write speeds are often blamed on the port. In one MakeUseOf test, the real cause was a Windows removal policy.

Writer Gregory Gibson ran the same flash drive on both sides of his laptop. Writes ran above 70 MB/s on the left and only about 24 MB/s on the right. The USB standard didn't explain the gap. Both ports reported SuperSpeed, and the right-hand ports weren't falling back to USB 2.0. The cause was a per-device Windows storage policy that someone had changed years earlier.

A Kingston USB drive sits beside a laptop showing contrasting transfer speeds and Windows removal policy settings. The test setup​

Gibson used CrystalDiskMark with the same settings throughout: three passes and a 1 GiB test file. He moved the same drive between ports.

He first used an older HP 250 G7 to see what a genuine USB 2.0 slowdown looks like. His figures were:

Port typeSequential readSequential write
USB 3.0 (marked SS)about 131 MB/sabout 78 MB/s
USB 2.0 (unmarked, 480 Mbps)about 37 MB/sabout 22 MB/s

That drop is what you'd expect from USB 2.0, and it hit reads as well as writes. His main laptop behaved differently. A 32 GB Kingston DataTraveler read at about 97 MB/s on both sides, but wrote at about 74 MB/s on the left and about 24 MB/s on the right. A slow port would normally drag reads down too, so a write-only gap pointed elsewhere.

Ruling out the hardware​

Gibson used the free USB Device Tree Viewer to map how each port connects. Both connections reported SuperSpeed. Both sat under the same Intel USB controller and root hub, with no extra hub in between. Matching link speed doesn't guarantee identical performance, but it removed the obvious explanations.

The clue was that the drive wouldn't eject cleanly from the left-hand ports. In the drive's Policies tab, the left connection was set to Better performance. The right was on Quick removal. The laptop's previous owner remembered changing the setting to speed up copying movies.

What the two policies do​

Microsoft's documentation, which applies to Windows 10 and Windows 11, describes the two policies like this:

  • Quick removal: Quick removal has been the default since Windows 10 version 1809. Earlier versions defaulted to Better performance. Windows keeps the device ready to unplug at any time. To do that, it can't cache disk writes, and Microsoft says this can degrade performance.
  • Better performance: This policy is meant to improve performance, and Windows can cache write operations to the external device. Microsoft says you must use Safely Remove Hardware, because that step lets cached operations finish. Unplugging without it risks data loss.

Microsoft also says you can set the policy per external device. It stays in effect when you reconnect the device to the same computer port. That fits Gibson's result. The same physical drive behaved differently on two ports because each port connection carried its own setting.

The before, change and restore result​

On the slow port, Gibson changed only the removal policy and left the "Enable write caching on the device" box unticked. That box was unticked on both ports. He then restored the original setting.

Right-side port settingSequential readSequential write
Quick removal (original)97.87 MB/s24.92 MB/s
Better performance97.48 MB/s71.96 MB/s
Quick removal (restored)98.78 MB/s24.75 MB/s

Writes roughly tripled and reads didn't move. Switching back brought the slow writes straight back. The repeatable pattern makes a good case that the policy caused the gap on this system.

How to check your own drive​

Microsoft's documented steps:

  1. Plug in the drive.
  2. Right-click Start and open Disk Management.
  3. In the lower pane, right-click the drive's label and choose Properties.
  4. Open the Policies tab and select the policy you want.
  5. If you don't see Policies, some recent Windows builds arrange the tabs differently. Select Hardware, pick the removable drive under All disk drives, choose Properties, and look for Policies again.

Microsoft also recommends ticking Enable write caching on the device if you choose Better performance. Gibson tested without it.

If you're troubleshooting, first confirm the negotiated link speed, for example with a tool like USB Device Tree Viewer. Then compare the removal policy between ports before blaming the hardware.

Caveats​

  • One system: These numbers come from Gibson's laptop and drive, not from independent testing. CrystalDiskMark's developer says results depend on test file size and position, fragmentation, controller and CPU. It also says results aren't comparable across major versions.
  • Gains vary: Reports on the benefit differ. WindowsForum has covered the topic before, noting that speed gains vary by drive. A Digital Citizen benchmark of a USB SSD found no meaningful difference between the policies. Flash drives with slow write controllers may show larger gaps, but that is my inference, not something these sources establish.
  • Sequential only: Real file copies, especially many small files, may behave differently from a sequential benchmark.
  • Safety: Better performance means you must eject before unplugging. Even under Quick removal, don't pull a drive while a transfer is running.
  • IT admins: Quick removal is the safer default for people who yank drives without ejecting. Changing it to Better performance trades some data-integrity safety for write speed.

Bottom line​

A drive that reads fast but writes slowly on one port isn't necessarily a bad port. Check the USB link speed first. Then check the removal policy, which may have been changed by a previous owner or a long-forgotten tweak. If you switch to Better performance, you need to start ejecting drives properly.

 

References

  1. My USB drive was much slower than expected, and one Windows setting was the reason MakeUseOf 2026-11-06T19:00:16+00:00
  2. Windows default media removal policy | Microsoft Learn learn.microsoft.com
  3. Windows default media removal policy learn-microsoft-com.translate.goog