Interactive Troubleshooter

Published: Oct 23, 2026

Why Does Copying Files Hang at 99%? - Bad Sector Diagnostic

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

Exhaustive diagnostic guide for resolving file copy operations that freeze or stall at 99% across local drives, USB storage, and network shares due to unrecoverable read/write bad sectors, dirty bit volume flags, write-caching buffer flushes, and antivirus filter driver locks.

Full Diagnostic Tree & Step-by-Step Overview

Where and under what specific conditions does the 99% file transfer freeze occur?

Transferring files to or from an internal HDD, SSD, or external USB storage drive.
Copying large single files or archive containers (ISO, ZIP, VHD) over a local network or SMB share.
Transferring thousands of small files where Explorer stops responding near completion.
Copying encrypted, compressed, or permission-restricted system files across volumes.

Select the storage device behavior and system logs observed during the 99% hang:

The drive active time spikes to 100% in Task Manager while read/write throughput drops to 0 KB/s.
Transfer speeds stay fast until 99%, then pause indefinitely while flushing the memory buffer to low-tier flash/SMR disk.
The external USB drive disconnects and reconnects or throws an I/O Device Error (0x8007045D).
Antivirus or Real-Time Protection locks the temporary target file during final payload scanning.

Select the specific network or SMB protocol symptom observed during the freeze:

SMB connection times out while finalizing remote file handle closing or metadata verification.
Network Interface Card (NIC) TCP Large Send Offload (LSO) causes packet loss on trailing file fragments.
NAS storage target (Synology, QNAP, TrueNAS) ZFS/RAID write-pool throttling or sync flush stall.
VPN or firewalled network connection drops TCP sessions during long-duration single file transfers.

Select the filesystem or batch copy condition matching your 99% stall:

NTFS Master File Table (MFT) corruption or dirty volume bit blocking directory index updates.
Windows Search Indexer or Volume Shadow Copy (VSS) holding file locks on newly created items.
File path length exceeds 260 characters (MAX_PATH limit) on remaining batch files.
Target drive formatted with FAT32/exFAT hitting single-file size or allocation block limits.

Select the security, encryption, or OS filter driver scenario matching your issue:

BitLocker or third-party volume encryption background re-encryption creating disk queue lockups.
Access Control List (ACL) security inheritance hanging while evaluating trailing file permissions.
Storage filter drivers (backup software, filter drivers) blocking I/O Completion Ports (IOCP).
SSD DRAM-less SLC cache depletion causing write performance degradation to sub-MB/s levels.

Fix: S.M.A.R.T. Bad Sector Identification and CHKDSK Sector Remapping

Solution:

Root Cause: Unrecoverable Read/Write Bad Sectors on Physical Media

When Windows Shell (File Explorer) copies a file, it reads sequential disk blocks. When encountering physical damage—such as uncorrectable ECC errors, magnetic degradation on HDDs, or dead NAND flash blocks on SSDs—the storage controller spends seconds or minutes retrying the I/O request. The Windows kernel I/O manager pauses progress at 99% (the final payload block) while waiting for the disk firmware to exhaust hardware read retries before throwing a hardware I/O timeout.

Diagnostic Verification:

Open PowerShell as Administrator and query S.M.A.R.T. drive counters using WMI:

Get-WmiObject -Namespace root\wmi -Class MSStorageDriver_FailurePredictStatus

Open Windows Event Viewer (eventvwr.msc), navigate to Windows Logs > System, and filter for Event ID 7, 11, or 154 sourced from disk or stornvme. Look for entries stating: *The device, \Device\Harddisk0\DR0, has a bad block.*

Step-by-Step Fix:

1Open an elevated Command Prompt by pressing Win + X and choosing Terminal (Admin) or Command Prompt (Admin).

2Run an offline surface scan and sector recovery pass on the affected drive letter (replace D: with your target drive letter):

cmd
   chkdsk D: /f /r /x

3Type Y if prompted to dismount the volume or schedule the check on the next system restart.

4If CHKDSK detects elevated counts of Bad Sectors (0 KB in bad sectors is expected for healthy drives), use Robocopy to perform an unbuffered copy that bypasses bad sectors without hanging File Explorer:

cmd
   robocopy C:\SourcePath D:\TargetPath /J /R:1 /W:1 /REG

*(Note: The /J switch enables unbuffered I/O, bypassing system caching; /R:1 limits retries on bad sectors to 1 second).* For official documentation on command flags, see the Microsoft Official Support Guide.

5If bad sectors continue expanding, replace the drive immediately as mechanical or NAND degradation is irreversible.

Prevention & Long-Term Monitoring:

Set up automated S.M.A.R.T. monitoring tools to alert on non-zero values for *Reallocated Sectors Count (ID 05)*, *Current Pending Sector Count (ID C5)*, or *Uncorrectable Sector Count (ID C6)*.

Fix: RAM Write-Caching and Buffer Flush Optimization

Solution:

Root Cause: Delayed Cache Flushing on Low-Speed or DRAM-less Drives

Windows utilizes system RAM as a write-back cache buffer to accelerate file transfers. File Explorer calculates progress based on data committed to system memory rather than physical media. When copying large files to slow USB drives or DRAM-less SSDs, the memory transfer reaches 100% almost instantly, but Explorer hangs at 99% while the OS blocks further operation to flush the dirty RAM pages to the physical storage device via standard sync commands.

Diagnostic Verification:

Open Task Manager, switch to the Performance tab, and select the destination disk.

Observe if Disk Transfer Rate displays steady write activity (e.g., 5–15 MB/s) while File Explorer's transfer window sits frozen at 99%.

Step-by-Step Fix:

1Press Win + X and select Device Manager.

2Expand Disk drives, right-click the target storage drive, and select Properties.

3Navigate to the Policies tab.

4Select Removal policy / Write-caching policy:

For external USB drives: Select Quick removal (default) to disable write caching on the device. This ensures progress bar accuracy.

For internal drives: Keep Enable write caching on the device checked, but uncheck 'Turn off Windows write-cache buffer flushing'.

5Open an elevated PowerShell prompt and disable global write-behind cache delays for specific copy jobs by utilizing Robocopy with direct unbuffered I/O:

powershell
   robocopy "C:\SourceFolder" "D:\DestinationFolder" "LargeFile.iso" /J

Prevention & Long-Term Monitoring:

Always use the 'Safely Remove Hardware and Eject Media' tray icon before disconnecting external storage to ensure all cached dirty memory pages are fully written.

Fix: USB Hub Power Delivery and Bus Reset Stabilization

Solution:

Root Cause: USB Controller Power Sag and I/O Timeout Dropping Packet Stream

External hard drives and unpowered USB hubs can experience minor voltage drops under prolonged high-current write operations. When voltage drops, the USB host controller resets the root hub (e.g., USB xHCI Compliant Host Controller), leading to a silent reset during the file closing handle phase, causing File Explorer to freeze at 99%.

Diagnostic Verification:

Check Event Viewer under System logs for Event ID 51 (An error was detected on device \Device\Harddisk1\DR1 during a paging operation) or Event ID 140 (An I/O operation initiated by the Registry failed).

Step-by-Step Fix:

1Open Device Manager via Win + X > Device Manager.

2Expand Universal Serial Bus controllers.

3Right-click every USB Root Hub and Generic USB Hub, select Properties, go to the Power Management tab, and uncheck Allow the computer to turn off this device to save power.

4Disable selective suspend in Windows Power Plan: Press Win + R, type powercfg.cpl, click Change plan settings > Change advanced power settings.

5Expand USB settings > USB selective suspend setting and change it to Disabled.

6Plug external high-power drives directly into motherboard USB ports (rear panel) or use a dedicated powered USB hub.

Prevention & Long-Term Monitoring:

Avoid using unpowered multi-port USB dongles for continuous data transfers exceeding 10 GB.

Fix: Real-Time Antivirus Scanner Exclusion for File Copy Operations

Solution:

Root Cause: Antivirus Filter Driver (Minifilter) Lock at File Handle Closure

Antivirus engines (Microsoft Defender, CrowdStrike, SentinelOne) attach filesystem filter drivers to monitor file operations. When a copy operation reaches 99%, the source file transfer is complete, but the OS invokes the CloseFile handle process. At this moment, the antivirus minifilter driver intercepts the stream to run heuristic scanning and archive extraction, holding the file handle open and freezing Explorer at 99%.

Diagnostic Verification:

Open Task Manager, go to the Details tab, and sort by CPU/Disk usage during a 99% hang. Look for processes like MsMpEng.exe (Microsoft Defender) or third-party security agents consuming high CPU or disk bandwidth.

Step-by-Step Fix:

1Open Windows Security from the Start Menu.

2Navigate to Virus & threat protection > Manage settings.

3Scroll down to Exclusions and click Add or remove exclusions.

4Click Add an exclusion and select Process, then enter robocopy.exe or exclude temporary staging target directories.

5If using PowerShell, add a process exclusion dynamically:

powershell
   Add-MpPreference -ExclusionProcess "robocopy.exe"

6Perform large batch transfers using Robocopy command-line execution to avoid File Explorer GUI handle blocking.

Prevention & Long-Term Monitoring:

Configure enterprise antivirus policies to skip real-time scanning on trusted backup target drives or specific high-throughput media volumes.

Fix: SMB File Locking and Opportunistic Locks (Oplocks) Tuning

Solution:

Root Cause: SMB Protocol Flush Delay and Opportunistic Locking Stalls

When transferring large files over a network via Server Message Block (SMB), the client requests Opportunistic Locks (Oplocks) to cache data locally. At 99% completion, the client issues an SMB2_CLOSE or SMB2_FLUSH command to confirm that all payload segments are written to network storage. If the remote SMB server or NAS is slow to flush its cache to disk, the client waiting thread blocks, hanging the copy process.

Diagnostic Verification:

Check the Windows Event Viewer on the client PC under Applications and Services Logs > Microsoft > Windows > SMBClient > Operational for Event ID 30803 or 30804 indicating connection timeouts.

Step-by-Step Fix:

1Open PowerShell as Administrator on the client system.

2Check current SMB configuration settings:

powershell
   Get-SmbClientConfiguration

3Increase the SMB bandwidth throttling limit and adjust buffer flush timeouts:

powershell
   Set-SmbClientConfiguration -EnableBandwidthThrottling $False -Confirm:$False
   Set-SmbClientConfiguration -FileInfoCacheLifetime 0 -Confirm:$False

4For stable large-file transfers over enterprise shares, execute the transfer with Robocopy unbuffered mode over SMB:

cmd
   robocopy \\Server\SourceShare \\Server\TargetShare LargeFile.vhdx /J /FFT /Z

*(Note: The /Z flag ensures the transfer is restartable if the network drops).*

Prevention & Long-Term Monitoring:

Ensure SMB 3.1.1 multichannel is enabled across both client and server to prevent single-channel buffer saturation.

Fix: Network Card Offload Engine and TCP Chimney Remediation

Solution:

Root Cause: Large Send Offload (LSO) TCP Packet Segmentation Corruption

Network Interface Card (NIC) drivers feature Large Send Offload (LSO) capabilities to offload TCP packet segmentation from the CPU to the network adapter hardware. Glitches in NIC firmware driver implementations can cause trailing TCP packets at the end of a transfer stream to drop, leading to infinite TCP retransmission loops at the 99% mark.

Diagnostic Verification:

Open PowerShell and check for elevated TCP retransmission counts during a file copy:

NetStat -s -p tcp

Check if disabling LSO immediately resolves network copy hangs.

Step-by-Step Fix:

1Open PowerShell as Administrator.

2Query active network adapter offload properties:

powershell
   Get-NetAdapterLso -Name "*"

3Disable IPv4 and IPv6 Large Send Offload across active network interfaces:

powershell
   Disable-NetAdapterLso -Name "*" -IPv4 -IPv6 -Confirm:$False

4Disable TCP Chimney and Receive Side Scaling (RSS) conflicts if packet loss persists:

powershell
   Set-NetOffloadGlobalSetting -ReceiveSideScaling Disabled -ReceiveSegmentCoalescing Disabled

5Retry the network copy operation.

Prevention & Long-Term Monitoring:

Keep network interface drivers updated directly from Intel, Realtek, or Marvell vendor sources rather than relying on generic Windows Update drivers.

Fix: NAS ZFS/RAID Sync Write Buffer Throttling

Solution:

Root Cause: ZFS Intent Log (ZIL) or RAID Controller Cache Exhaustion

When copying data to Network Attached Storage (NAS) running ZFS or hardware RAID, incoming writes are initially buffered in the storage pool's RAM or write cache. When copying a large file that exceeds the RAM write cache, the NAS forces synchronous writes (sync) to persistent pool disks, dropping throughput to zero while the storage pool catches up, leaving the client stuck at 99%.

Diagnostic Verification:

Access the NAS administrative console (e.g., Synology DSM, QNAP QTS, TrueNAS SCALE) and review disk pool I/O usage and latency metrics during the transfer.

Step-by-Step Fix:

1Open your NAS web management interface.

2Navigate to Storage Manager > Storage Pool / Volume settings.

3Verify that write-back caching is enabled on the RAID array if a battery-backed write cache (BBWC) or UPS is present.

4For ZFS-based systems (TrueNAS), review the pool's SLOG (Secondary Storage Log) SSD health or temporarily toggle dataset sync behavior for non-critical targets:

bash
   zfs set sync=standard tank/dataset

5Adjust SMB write buffer limits on the NAS SMB server configuration (smb.conf):

ini
   aio write size = 16384
   use sendfile = yes

Prevention & Long-Term Monitoring:

Provision dedicated NVMe SSD write caches (SLOG/LOG devices) on NAS storage pools handling heavy continuous write loads.

Fix: VPN MTU Size Adjustment and TCP MSS Optimization

Solution:

Root Cause: IP Packet Fragmentation and Path MTU Black Hole

When copying files across a VPN tunnel (OpenVPN, WireGuard, IPsec), encapsulation headers increase packet overhead. If the Maximum Transmission Unit (MTU) size exceeds the network path limit, routers fragment packets. When the final framing packets at 99% are dropped due to missing Don't Fragment (DF) flag handling, the session hangs waiting for ACK responses.

Diagnostic Verification:

Ping the remote target host across the VPN with non-fragmented packets to determine MTU limits:

ping 192.168.1.50 -f -l 1472

Lower the length byte value until ping responses succeed without packet fragmentation error messages.

Step-by-Step Fix:

1Open Command Prompt as Administrator.

2Find your active VPN adapter name:

cmd
   netsh interface ipv4 show subinterfaces

3Adjust the MTU size of the VPN interface to a stable non-fragmented value (e.g., 1350 or 1400):

cmd
   netsh interface ipv4 set subinterface "VPN Connection" mtu=1350 store=persistent

4Re-run your network copy test to confirm uninterrupted completion.

Prevention & Long-Term Monitoring:

Enable Path MTU Discovery (PMTUD) across perimeter firewalls and router configurations.

Fix: NTFS Dirty Bit Clearing and File System Metadata Repair

Solution:

Root Cause: Volume Dirty Bit Flag and Corrupt MFT Allocation Records

If a volume experienced an abrupt shutdown or physical disconnection during a previous write event, Windows sets the volume's 'dirty bit'. When copying new files to a dirty volume, the NTFS driver forces validation checks on Master File Table (MFT) record updates before closing file handles, halting operations at 99%.

Diagnostic Verification:

Open PowerShell as Administrator and query the volume dirty status:

fsutil dirty query D:

If the output states Volume - D: is Dirty, file creation and metadata closing operations will be throttled or blocked by the OS kernel.

Step-by-Step Fix:

1Open an elevated Command Prompt.

2Schedule a thorough volume check to clear the dirty bit and repair MFT index allocations:

cmd
   chkdsk D: /f /r

3If CHKDSK reports that the volume is locked, type Y to restart the computer and perform the scan during early boot.

4Once Windows reboots, verify that the dirty bit is cleared:

cmd
   fsutil dirty query D:

5Test the file copy operation to confirm proper functionality.

Prevention & Long-Term Monitoring:

Never forcibly unplug external storage devices without properly ejecting them or shutting down the operating system.

Fix: Windows Search Indexer and Volume Shadow Copy Lock Mitigation

Solution:

Root Cause: Concurrent File Locking by Search Indexer or VSS Writers

As soon as a new file reaches 99% progress, Windows Search Indexer (SearchIndexer.exe) or Volume Shadow Copy Service (vssvc.exe) attempts to read the partial file handle to extract metadata (properties, EXIF data, preview thumbnails). This creates a file-locking race condition with File Explorer, blocking the final write completion signal.

Diagnostic Verification:

Download and run Microsoft Sysinternals Process Explorer, press Ctrl + F, and search for the filename stuck at 99% to identify which process holds an active file handle lock.

Step-by-Step Fix:

1Open Services by pressing Win + R, typing services.msc, and pressing Enter.

2Scroll down to Windows Search, right-click it, and click Stop.

3Scroll down to Volume Shadow Copy, right-click it, and click Stop.

4Exclude high-throughput copy target directories from indexing:

Open Control Panel > Indexing Options.

Click Modify and uncheck target backup/data volumes.

5Retry the copy operation using Command Prompt or PowerShell.

Prevention & Long-Term Monitoring:

Disable Windows Search indexing on dedicated secondary storage or backup volumes that do not require instant search capabilities.

Fix: Long Path (MAX_PATH 260 Character Limit) Registry Enablement

Solution:

Root Cause: Win32 API MAX_PATH 260 Character Limit Truncation

By default, the Windows Win32 API imposes a maximum path length limit of 260 characters (MAX_PATH). When copying deep folder structures, File Explorer copies files until it hits a file whose fully qualified path exceeds 260 characters. Explorer stalls at 99% while attempting to allocate directory entry space for the invalid path string.

Diagnostic Verification:

Check if the transfer hangs on specific deeply nested subfolders or files with long names.

Step-by-Step Fix:

1Open PowerShell as Administrator.

2Enable Win32 Long Paths in the Windows Registry:

powershell
   Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1

3Alternatively, enable long paths via Group Policy Editor (gpedit.msc):

Navigate to Computer Configuration > Administrative Templates > System > Filesystem.

Double-click Enable Win32 long paths, select Enabled, and click OK.

4Force a Group Policy refresh:

cmd
   gpupdate /force

5Perform the file transfer using Robocopy, which natively supports long paths up to 32,767 characters:

cmd
   robocopy "C:\DeepSource" "D:\DeepTarget" /E /COPYALL

Prevention & Long-Term Monitoring:

Keep LongPathsEnabled set to 1 across all corporate Windows workstation images.

Fix: FAT32 4GB File Size Limit and File System Conversion

Solution:

Root Cause: Attempting to Copy Files Exceeding 4GB to FAT32 Volumes

The legacy FAT32 file system uses 32-bit fields in its directory entries to store file sizes, capping single file sizes at 4,294,967,295 bytes (4GB minus 1 byte). When copying a file larger than 4GB (e.g., ISOs, virtual disks, video files) to a FAT32 drive, File Explorer buffers data up to the 4GB boundary (often reaching 99%) before failing to write the final clusters, resulting in a permanent freeze.

Diagnostic Verification:

Check the destination drive properties in File Explorer (Right-click drive > Properties) to verify if the file system is identified as FAT32.

Confirm if the single file being copied exceeds 4,294,967,295 bytes in size.

Step-by-Step Fix:

1Open Command Prompt as Administrator.

2Convert the destination FAT32 drive to NTFS without losing existing data (replace D: with your drive letter):

cmd
   convert D: /fs:ntfs

3If cross-platform compatibility with macOS or Linux is required, reformat the drive to exFAT (Note: Formatting erases drive contents; back up data first):

cmd
   format D: /FS:exFAT /Q

4Retry copying the large file to the converted NTFS or exFAT drive.

Prevention & Long-Term Monitoring:

Always format high-capacity USB drives (64GB+) using exFAT or NTFS rather than legacy FAT32.

Fix: BitLocker Background Encryption and IOPS Allocation Tuning

Solution:

Root Cause: BitLocker Volume Encryption Engine I/O Preemption

If BitLocker drive encryption is actively encrypting or decrypting a volume in the background, the BitLocker filter driver (fvevol.sys) preempts write operations to ensure sector-by-sector cryptographic integrity. High disk write queues cause File Explorer file completion handle requests to stall at 99%.

Diagnostic Verification:

Open PowerShell as Administrator and check BitLocker status:

Get-BitLockerVolume

Verify whether EncryptionPercentage is actively processing or at 100% Fully Encrypted.

Step-by-Step Fix:

1Open PowerShell as Administrator.

2Pause BitLocker background conversion temporarily during heavy file transfers:

powershell
   Suspend-BitLocker -MountPoint "D:" -RebootCount 0

3Resume file copy tasks using Robocopy unbuffered mode to maintain priority disk scheduling:

cmd
   robocopy C:\Source D:\Target /J /MT:8

4Once copying completes, resume BitLocker protection:

powershell
   Resume-BitLocker -MountPoint "D:"

Prevention & Long-Term Monitoring:

Complete full BitLocker encryption or decryption cycles prior to initiating high-volume data migration tasks.

Fix: NTFS Access Control List (ACL) Inheritance Reset

Solution:

Root Cause: Broken ACL Inheritance Traversal on Destination Folders

When copying files into directories with restricted or explicitly broken NTFS permissions, the copy process writes file data blocks successfully. However, at 99% completion, the system appliesinherited Security Descriptors (ACLs) to the new file handle. If permission inheritance traversal fails due to orphaned SIDs or denied access, the operation hangs waiting for elevation response.

Diagnostic Verification:

Check if copying the exact same file to a generic root directory (e.g., C:\Temp) succeeds without hanging.

Step-by-Step Fix:

1Open Command Prompt as Administrator.

2Take ownership of the target parent directory (replace D:\TargetFolder with your path):

cmd
   takeown /f "D:\TargetFolder" /r /d y

3Reset permissions and restore clean inheritance across all subdirectories:

cmd
   icacls "D:\TargetFolder" /reset /t /c /l /q

4Grant full control permissions to the active user account:

cmd
   icacls "D:\TargetFolder" /grant %username%:(OI)(CI)F /t

5Retry the copy operation.

Prevention & Long-Term Monitoring:

Avoid manually removing inherited permissions from top-level parent directories on shared volumes.

Fix: Storage Filter Driver Stack Diagnostics and Detachment

Solution:

Root Cause: Non-Compliant Storage Filter Driver Stalling I/O Completion

Fix: SSD SLC Cache Depletion and Thermal Throttling Mitigation

Solution:

Root Cause: DRAM-less SSD Pseudo-SLC Cache Exhaustion

Modern low-cost SSDs (QLC/TLC NAND) utilize a portion of fast NAND flash operating in pseudo-SLC mode as a high-speed write cache. During large file transfers, once the SLC cache buffer is completely filled, the SSD controller must directly write data to raw QLC/TLC cells while simultaneously executing garbage collection routines. Disk write speeds drop from 2,000 MB/s to sub-10 MB/s levels, making progress stall at 99% while the controller processes remaining queued blocks.

Diagnostic Verification:

Monitor SSD internal temperature and write speeds using diagnostic tools (e.g., HWiNFO or manufacturer SSD utilities).

Observe if write performance starts extremely high and abruptly drops to near-zero write throughput after transferring 20–50 GB.

Step-by-Step Fix:

1Allow the SSD to sit idle for 10–15 minutes so the controller can flush its pseudo-SLC cache to primary storage blocks via background TRIM routines.

2Manually trigger a TRIM optimization pass via PowerShell:

powershell
   Optimize-Volume -DriveLetter D -ReTrim -Verbose

3Ensure adequate thermal dissipation on M.2 NVMe SSDs by attaching heatsinks or improving enclosure airflow to prevent thermal throttling.

4Use Robocopy with rate-limiting bandwidth options (/IPG inter-packet gap) to restrict write speeds within the drive's sustained native write capabilities:

cmd
   robocopy C:\Source D:\Target LargeFile.iso /J /IPG:5

Prevention & Long-Term Monitoring:

Select DRAM-equipped high-end SSDs with large sustained write caches for workloads requiring continuous multi-gigabyte file transfers.

Related Diagnostic Guides

Windows Update Error 0x80070002 Missing Files Diagnostic Guide

System Restore Failed 0x80070005 Antivirus Conflict Tree

Windows Photo Viewer Not Showing Thumbnails: Codec Diagnostic

Safe Mode Password Not Working With Microsoft Account Fix

Clipboard History Not Working Windows 11: Sync Service Tree

Subscribe to StepDiag

Embed Guide on Your Website