Many developers encounter issues when trying to programmatically eject USB drives via PowerShell. The traditional WMI approach often returns cryptic exit codes without successfully unmounting the drive. Let me share my battle-tested solution that goes beyond basic documentation.

The root issue lies in how Windows handles volume management. When you call Dismount() on a Win32_Volume object, Windows checks for:

• Active file handles
• System processes accessing the volume
• Pending I/O operations
• Volume shadow copies

Here's my enhanced script that combines multiple techniques:

# First attempt graceful dismount
$drive = Get-WmiObject Win32_Volume -Filter "DriveLetter = 'F:'"
$result = $drive.Dismount($false, $false)

if ($result.ReturnValue -ne 0) {
    # Use diskpart for forceful removal
    $diskpartScript = @"
select volume F
remove all dismount
"@
    $diskpartScript | diskpart
    
    # Alternative using CIM (newer than WMI)
    $volume = Get-CimInstance -ClassName Win32_Volume -Filter "DriveLetter = 'F:'"
    Invoke-CimMethod -InputObject $volume -MethodName Dismount -Arguments @{
        Force = $true
        Permanent = $false
    }
    
    # Final check using mountvol
    mountvol "F:" /D /L
}

For exit code 2 (existing mount points), we need deeper diagnosis:

# Check for open handles
$handleInfo = handle.exe -p explorer.exe -a F:\
if ($handleInfo) {
    Stop-Process -Name explorer -Force
    Start-Process explorer.exe
}

# Check for volume shadow copies
Get-WmiObject Win32_ShadowCopy | Where-Object {
    $_.VolumeName -like "*F:*"
} | Remove-WmiObject

For production environments, consider this robust function:

function Dismount-USBDrive {
    param(
        [Parameter(Mandatory=$true)]
        [string]$DriveLetter,
        
        [bool]$Force = $false,
        [bool]$Permanent = $false
    )
    
    process {
        try {
            # Normal WMI approach
            $vol = Get-WmiObject Win32_Volume -Filter "DriveLetter = '$($DriveLetter):'"
            $result = $vol.Dismount($Force, $Permanent)
            
            if ($result.ReturnValue -eq 0) {
                return "Successfully dismounted $DriveLetter"
            }
            
            # Enhanced methods
            $mountvolResult = (mountvol "${DriveLetter}:" /D /L 2>&1)
            if ($LASTEXITCODE -ne 0) {
                throw "Mountvol failed: $mountvolResult"
            }
            
            # Final verification
            if (Test-Path "${DriveLetter}:\") {
                Write-Warning "Drive still appears mounted - system refresh may be needed"
            }
        }
        catch {
            Write-Error "Dismount failed: $_"
        }
    }
}

This multi-pronged method accounts for various Windows subsystems that might lock the volume. The sequence:

1. Attempts standard WMI dismount
2. Falls back to diskpart for low-level control
3. Uses mountvol as a final option
4. Includes cleanup of shadow copies and handles

Remember that some enterprise environments may have additional security measures preventing drive dismount. In such cases, consult your system administrators about Group Policies affecting removable storage.

Many Windows administrators encounter situations where standard USB ejection methods fail, particularly when dealing with stubborn external drives. Through extensive testing, I've found the WMI Win32_Volume approach often requires additional handling compared to the simple GUI eject method.

The fundamental PowerShell structure for drive ejection should be:

# First get the volume object
$volume = Get-WmiObject Win32_Volume -Filter "DriveLetter = 'F:'"

# Then attempt dismount with force option
$result = $volume.Dismount($true, $false)

# Verify operation success
if($result.ReturnValue -eq 0) {
    Write-Host "Successfully ejected drive"
} else {
    Write-Host "Failed with error code: $($result.ReturnValue)"
}

Several factors can prevent successful ejection:

• File handles being held by applications (use Handle.exe from Sysinternals to check)
• Volume shadow copies (disable VSS temporarily if needed)
• Indexing service interference

When drive letters prove unreliable, use the volume GUID instead:

$vol = Get-WmiObject Win32_Volume | Where-Object {
    $_.DriveLetter -eq 'F:' 
}

$vol.Dismount($true, $false)

# Critical - must save changes back to WMI
$vol.Put() | Out-Null

Here's a robust function I've developed through trial and error:

function Safe-EjectDrive {
    param(
        [Parameter(Mandatory=$true)]
        [string]$DriveLetter
    )
    
    try {
        $vol = Get-WmiObject Win32_Volume -Filter "DriveLetter = '$($DriveLetter)'"
        if(-not $vol) { throw "Drive not found" }
        
        $result = $vol.Dismount($true, $false)
        if($result.ReturnValue -ne 0) {
            throw "Dismount failed with code $($result.ReturnValue)"
        }
        
        $vol.Put() | Out-Null
        return $true
    }
    catch {
        Write-Error $_.Exception.Message
        return $false
    }
}

After calling the dismount method, verify with:

Get-Volume -DriveLetter F | Select-Object OperationalStatus

Should return "Offline" status for successfully ejected drives.