How to handle Bitlocker and Standby

[Remural]

I've been using Drivepool for a couple years now. It always bothered me that the drives weren't going to sleep and I want to fix it now. Since I use Bitlocker, I'm aware I need to set the Bitlocker_PoolPartUnlockDetect to false. 

But then what? Should I use the task manager to restart the drive pool service whenever I reattach my external USB drives? What about the native service? And why is a full restart necessary that takes quite long? Can't the UI just give me a refresh button that does once what the constant polling does currently?

Besides I am sure there are possibilities to figure out if a bitlocker encrypted drive has been unlocked or not, without waking the drive up. My Windows event log shows under application and service protcols --> Microsoft --> Windows --> Bitlocker-API --> Management the events with ID 782 for when a volume was unlocked and 781 for when it was locked. It even gives a volume device path to indicate which volume was locked/unlocked in the \\?\Volume{<GUID>} format. If Drivepool can subscribe to that event log it would fix this long standing issue I and many other users are experiencing.

[Christopher (Drashna)]

You shouldn't need to mess with the native service. Mostly, it makes sure that the system shutdown doesn't happen until the service has shut down/ended gracefully.  

But yes, restarting the "StableBit DrivePool Service" should refresh the drive list.  

On 7/4/2026 at 11:30 AM, Remural said:

But then what? Should I use the task manager to restart the drive pool service whenever I reattach my external USB drives? What about the native service? And why is a full restart necessary that takes quite long? Can't the UI just give me a refresh button that does once what the constant polling does currently?

As for why... most of this should happen invisibly, and the goal is to make sure it does.   Unfortunately, the bitlocker detection causes issues on some systems.

As for "full restart", do you mean of the service?  If so, it's because it's loading setting from disk, checking hardware config, and running startup routines (such as checking if the pool needs mounting, etc).  Depending on the system and number of disks, this can take a bit to complete. 

There are some advanced settings that may help, but depend on having more cores in your CPU, basically (eg, by using more threads to run background tasks).

On 7/4/2026 at 11:30 AM, Remural said:

Besides I am sure there are possibilities to figure out if a bitlocker encrypted drive has been unlocked or not, without waking the drive up. My Windows event log shows under application and service protcols --> Microsoft --> Windows --> Bitlocker-API --> Management the events with ID 782 for when a volume was unlocked and 781 for when it was locked. It even gives a volume device path to indicate which volume was locked/unlocked in the \\?\Volume{<GUID>} format. If Drivepool can subscribe to that event log it would fix this long standing issue I and many other users are experiencing.

That's the thing, we are using the officially support API to check.  It's that API that is what causes the drives to wake up on some systems, because Windows considers that activity, and wakes the drive.

As for listening to the event viewer, I'm sure that's possible, but as you may have seen, that is a LOT of data to parse, and may cause other issues. 

[Remural]

18 minutes ago, Christopher (Drashna) said:

As for "full restart", do you mean of the service?  If so, it's because it's loading setting from disk, checking hardware config, and running startup routines (such as checking if the pool needs mounting, etc).  Depending on the system and number of disks, this can take a bit to complete. 

There are some advanced settings that may help, but depend on having more cores in your CPU, basically (eg, by using more threads to run background tasks).

I don't mind that a service restart needs that long. I do mind that I need to restart the service to tell Drivepool that it should look for newly unlocked drives. I assume that currently there is some timer that is called every 5 seconds or so which calls a callback that checks if Bitlocker has unlocked drives if Bitlocker_PoolPartUnlockDetect is enabled (by default).

I don't like to not having no standby for my disks at all. I have many of them in my room and the noise is very annoying. A small button in the Drivepool UI could call the aformentioned callback once, even if Bitlocker_PoolPartUnlockDetect is disabled. This is much easier and faster than restarting the whole drivepool service in the task manager. Although I would much more prefer the solution through the event log.

18 minutes ago, Christopher (Drashna) said:

That's the thing, we are using the officially support API to check.  It's that API that is what causes the drives to wake up on some systems, because Windows considers that activity, and wakes the drive.

As for listening to the event viewer, I'm sure that's possible, but as you may have seen, that is a LOT of data to parse, and may cause other issues. 

If the official API has some severe drawbacks like in this case waking the drives up, it is a good idea to look for alternatives.

The Windows event log allows to subscribe to specific channels decribed here. The channel I mentioned only contains a small number of events. For me its 95%+ bitlocker unlock events, so you won't have to look at many events. The function to subscribe to a channel also allows to write a filter (like for an event ID), so your application is only called for unlock and lock events. And we can agree that that happens very rarely. Basically after subscribing, your callback only gets the relevant information. Then, you only need to get the volume name out of that event using the provided event rendering functions described here.

If you think how many threads there are in this forum about problems with standby, this is an easy win and from a complexity standpoint of view much simpler than the functionality thats already in Drivepool.

[Christopher (Drashna)]

Well, part of the issue is that we do try to minimize disk queries.  StableBit Scanner (and the other products) look for disk change notifications. Eg, when a disk is connected, disconnected, etc.  However, the bitlocker stuff it a special case. 

On 7/6/2026 at 3:21 PM, Remural said:

If the official API has some severe drawbacks like in this case waking the drives up, it is a good idea to look for alternatives.

Our official stance on this is "no, it's not a good idea, it's actually a really bad idea".  Official methods are official for a reason, and using shortcuts, hacks, and other non-official methods means that those behaviors are not documented and not supported.  And in fact, are likely to be patched out of existence.    Using them leads to an unstable or even unusable product.   And we're actively opposed to that, because we have no desire to build, to be very blunt, a shitty product. 

 

However, I've passed on the request to Alex, the developer, to see if there is a way that we can improve things here.   Because there is always room for improvement, but sometimes it can take an outside perspective.

https://stablebit.com/Admin/IssueAnalysis/29129
This won't show any info unless it's posted publicly. Generally, the posts are public, but if there are code changes based on this, those are always public.  So I'm posting here so if there is a change or public explantation, it's accessible here. 

[Remural]

Thanks for forwarding this to your developer Alex.

I just wanted to say that this method I proposed is in no way a hack or non-official method. The event log API is there since Windows Vista, same time since Bitlocker is around. The specific unlock messages are probably in there since its release.  Could be investigated by setting up a VM. I also would not expect any relevant changes in already present functionality. Microsoft knows that there is software around relying on the data from the event log because of the aforementioned API. It's likely that they add new events, or alter the textual description of existing events or add more data to existing events. But I would not expect breaking changes like altered event ids or missing fields. But I'm sure Alex has lots of experience with Windows development and hopefully comes to a similar assessment.

[Christopher (Drashna)]

You are very welcome.    

[Christopher (Drashna)]

Just a heads up, Alex did take a look into this, and did find a solution that is actually lower level, shouldn't keep the drives awake and allow them to sleep.  

Quote

* [Issue #29129] Implemented a more efficient BitLocker volume unlock detection method that does not prevent drives from going to sleep.
    - This new method listens for PnP events. If anything goes wrong, it will fall back to WMI-based polling.
    - Can be disabled with a new advanced setting, BitLocker_FileSystemMountDetect (default: true). 
    - The BitLocker_PoolPartUnlockDetect advanced setting, which controls WMI-based detection, now defaults to false.

You can find the installer for this version here:

https://dl.covecube.com/DrivePoolWindows/beta/download/StableBit.DrivePool_2.3.14.1744_x64_BETA.exe

 

 

[Remural]

That's great news! 

The new version works perfectly and now the drives finally go to sleep as they should.

[Christopher (Drashna)]

Awesome, glad to hear it!  And thank you for pushing back/insisting on a better fix.