Getting a drive REdetected

[Sebastian42]

In my x32Win10ProV22H2 desktop tower, I have SATA-connected drives whose power can be switched ON (and OFF) as required. The BIOS has been set to AHCI, so all connected drives should be 'hot-swapable' [or whatever the CORRECT term for that is]. Yet from time to time, newly connected (i.e. newly powered) drives, do not get detected unless I reboot the PC. What tweak will force detection without rebooting ? In vain, I have tried mechanisms involving re-scanning for drives in Disk Management, in DiskPart and in Command Prompt (with 'pnputil /scan-devices') and in Device Manager (Scan for hardware changes). What other options are there ?

 

[Rick998]

Have you tried either of the following from a PowerShell script?:

Get-PSDrive

or

Get-PSDrive -PSProvider FileSystem

You don't need any output, just enumeration. The docs say (re)connected drives add a PSDrive object so this suggests there must be some (re)enumeration going on.

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-psdrive?view=powershell-5.1[/URL]]Also, beginning in Windows PowerShell 3.0, when an external drive is connected to the computer, Windows PowerShell automatically adds a PSDrive to the file system that represents the new drive.

Hope this helps...

 

[Sebastian42]

No, I have not tried Powershell, but it seems to offer a new potential option. I can not test it immediately as I have to wait till the dysfunction re-occurs.
Could I impose on you to spell out the steps involved - for starters how to launch Powershell, and then how to 'enter' either (both ?) of the codes you've provided ?

 

[Rick998]

I suggest you first test manually whether it works before thinking about automation run from, say, a desktop shortcut.

For example, when the dysfunction re-occurs:
1. Right-click on Start and choose Windows PowerShell from the context menu.
2. When the console opens, copy/paste or type gdr.
(gdr is the 'alias' for the Get-PSDrive cmdlet. Think of it as 'get drives for the current session'.)
3. The console will show you the results. If the results include your re-connected drive then you know re-enumeration has worked.
4. If the results don't include your re-connected drive then close the console and do the following:
5. Right-click on Start and choose Windows PowerShell (Admin). This will open a console with elevated privileges.
6. When the console opens, repeat step 2 and see if the results include your re-connected drive. If so then it means re-enumeration requires elevated privileges.
7. Post back.

Hope this helps...

 

[Sebastian42]

Only a fool could get it wrong with such detailed steps mapped out. Thank you so much.

 

[Rick998]

... unless, of course, another fool mapped out the detailed steps in the first place. I don't have a means to test this, so it's guesswork (and hope) at best I'm afraid.

I'm aware that there's a method to invoke a refreshed enumeration of hardware using C, C++, etc. but I have no idea how to invoke a similar method using PowerShell. Sorry.

 

[Sebastian42]

'but I have no idea how to invoke a similar method using PowerShell' - That confuses me. I thought that is what you had done.
C and C+ I have heard off, but never used.

 

[Rick998]

'but I have no idea how to invoke a similar method using PowerShell' - That confuses me. I thought that is what you had done.

What I said in my earlier post was:

The docs say (re)connected drives add a PSDrive object so this suggests there must be some (re)enumeration going on.

This implies that it may work according to the docs... which is why I then suggested you testing it manually that it worked as you wanted.

I don't have a similar setup with switchable SATA drives so I cannot test the result of the PowerShell cmdlet for you.

 

[Sebastian42]

Yes, of course I have to test it. It's insightful of you to predict that if it works, I want it to implementable as simply as possible - you mentioned a batch file - that is what I was hoping to be able to do it with. I expect that constructing that will not be simple, but first things first. Let's see if Powershell can do what four other methods could not.

 

[Rick998]

If the PowerShell cmdlet works for you as you need it to then it should be simplicity itself to implement as a PowerShell file (.ps1) and run it.

I'm currently testing a free, tiny, signed executable from a very respected developer that will make it simple to create a desktop shortcut that will run a PowerShell script with no visible elements whatsoever.

Even better, it looks like it will run the cmdlet with parameters (i.e. Get-PSDrive -PSProvider FileSystem). This will make the script faster in operation 'cos it will only try to re-enumerate physical drives, not virtual 'PS-Provider' drives.

See RunHidden App for more info.

 

[Sebastian42]

'virtual 'PS-Provider' drives.' is beyond me, but I'm quite confident that the drives I want detected are 'physical drives'.

'I'm currently testing..' so that must be a work-in-progress that you will 'confirm' in due course ?

 

[Rick998]

'I'm currently testing..' so that must be a work-in-progress that you will 'confirm' in due course ?

Yep. It was only published today... but I already have many uses for it.

If all goes well it will solve many automation and security issues plus save me having to write copious step-by-step instructions. I'll be able to just write a simple template 'how to'.

It is tedious compiling PowerShell scripts myself and recipients quite rightly don't trust them because I currently have no method (nor intention) to code-sign the resulting executable.

 

[Sebastian42]

'code-sign the resulting executable' I have no idea what that means, but so long as the code works I will be satisfied.

 

[Sebastian42]

The malfunction happened today - sad to say, re-enumeration via Powershell is no better than all the other methods.

To my surprise, after switching the new external's power off because of Powershell's failure to get it detected, it showed in File Manager when I switched it on again - MAYBE Powershell made the difference, but in an unexpected way. Time will tell when the malfunction occurs again, and I try Powershell again.....

 

[Sebastian42]

My surprise has been duplicated - with a different drive not being detected until I tried a second time. When it happens again, I will toggle the power again BEFORE running Powershell, to see if that was the solution, or the Powershell procedure.
Because the instructions say to see if enumeration lists the undetected drive - and in both cases it was not listed in the Powershell dialog.

 

[Sebastian42]

Yet again - it seems that it is not Powershell that makes the difference, but just repeating the powering up of the drive. I will try it another few times before I make up my mind.

 

[Sebastian42]

I tried to apply rigorous controls this time. When a drive was not detected, I toggled the power - that did not fix it, so I could rule out
toggling-power/reconnecting. Then I did the Powershell thing - it did not cause detection; nor when I toggled the power afterwards. What did cause detection was reseating the SATA leads into the SSD. That is still better than rebooting, but has not always been the solution in the past.

 

[Sebastian42]

It rather looks like the most promising technique is to depower the drive and power it again - that fixes it SOMETIMES if not always.

 

[Rick998]

My apologies for resurrecting a zombie thread but I only just noticed it.

I have the same issue with a couple of HDDs in external USB caddies.

Once the HDDs power themselves down it needs a power-off/power-on cycle for them to signal themselves as available again. This enforced sleep interval appears hardcoded in the drive's onboard chipset... so I cannot amend it.

It's a complete 'pain in the posterior' and the only way I've found to work around it is to use a third-party utility to keep the drive alive every few minutes before the 'sleep' timer activates.

See KeepAliveHD

Hope this helps...