I've written a bunch of PowerShell scripts to run disk checks, which worked great until recently. Now, when I run these scripts, they fail to unmount the volume, even though I'm prompting for admin rights at the start. Each script is designed for a different drive and can run simultaneously. However, the script for the largest drive manages power settings to hibernate my PC after completion, which is crucial for efficiency.
When I run the scripts, I get a message saying it can't lock the current drive because it's in use by another process. This doesn't happen when I run the chkdsk command directly in an elevated Command Prompt. The problem seems to lie in how I'm calling the chkdsk command through PowerShell. I posted the relevant code on Pastebin, and I suspect the issue may be with how I'm determining the drive letter. I've tried testing different modifications, but I can't nail down the root cause. Any insights would be appreciated!
3 Answers
It might be an issue with the drive being in use by other applications, not just your script. Have you checked to see if any background processes might be accessing the volume? You could use tools like Process Explorer to check which processes might have a lock on the drive.
It sounds like you might be facing an issue with how PowerShell handles the execution context. When you call chkdsk from within a script, it might not have the same privileges or may not properly access the drive status. I’d suggest simplifying your script to isolate the issue. You might want to test directly running `chkdsk` multiple ways to see if any particular context is required.
I noticed you've mentioned the way you're fetching the drive letter (`Get-OriginDriveLetter`). Ensure that this function is actually returning just the letter without any extra symbols like colons. You can format that to make sure it's clean before you pass it to chkdsk. Also, consider replacing `Get-WmiObject` with `Get-CimInstance` as it’s more modern and efficient.
Thanks for the tip! I’ll try breaking it down and see if running it in different contexts makes a difference. I guess I should also check for running processes that might be holding the drive.