Christopher (Drashna)

I know there have been a few tickets about this. Unfortunately, neither Alex nor I have had any luck at reproducing the issues locally. If you haven't already, open a ticket at https://stablebit.com/contact If you have previously opened a ticket about this, then if you could, open a new ticket. Getting drive tracing from when this is happening would be very helpful, and can be done when opening the ticket (eg grab the logs, upload and attach during ticket creation): https://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection And afterwards, run the StableBit Troubleshooter. And as much information about the files that this is most commonly happening on. And exact steps to reproduce the issue, if possible. Because issues like this, when we can't reproduce them, are much more difficult to track down. Let alone fix.

I hear you on that! Less complexity does mean less that can go wrong. For the UI, what do you mean that it has gone "bye-bye"? Are the UI's showing up at all but with black screens? Or not showing up at all? Or? And Veeam is very nice to use, for sure! If this is StableBit DrivePool related, and only happens when it is installed, then this might be useful for us, at least: https://wiki.covecube.com/StableBit_DrivePool_System_Freeze This does trigger a BSOD (so an unsafe shutdown), but dumps the active memory to disk. This can be incredibly helpful information, if you know how to read these memory dumps (I only kinda do, but Alex, the developer, is a pro at these).

Yeah, that +12V line will get you. IIRC, it's also further broken up by cable/rail. But definitely something to check!

By chance, do you have any especially large files? Like TBs in size?

Do you have MSI Afterburner installed, or otherwise are overclocking your GPU? If so, it can cause this sort of behavior. Also, using Remote Desktop (or sometimes, remote access software) can cause this to happen, too. Specifically, in cases like this, the issue usually is with the GPU, as .NET Framework uses hardware accerleration for the graphics (which our software uses). You can disable this per app by renaming the "C:\Program Files\StableBit\DrivePool\DrivePool.UI.exe.default.config" to "DrivePool.UI.exe.config" (in the same folder), and setting the "SoftwareOnlyRendering" value to "True", saving the file and re-opening the UI (make sure it's not running in Task Manager, first). You can also disable the hardware accerleration globally: https://learn.microsoft.com/en-us/dotnet/desktop/wpf/graphics-multimedia/graphics-rendering-registry-settings?view=netframeworkdesktop-4.8#disable-hardware-acceleration-option Specifically, the "DisableHWAcceleration" value, and setting this to 1 and rebooting.

If you have StableBit CloudDrive installed, it does have some cleanup that has to occur before a full shutdown can take place. Namely, it has to flush all the data to disk, which is fun because flushing data t othe clouddrive disk causes writes to the cache drive , which then also need to be flushed. However, this definitely shouldn't take two days. And if the system is running the "shutting down" screen, it should usually list a service that it is waiting on (like the StableBit CloudDrive Service). However, if you don't have that installed, StableBit DrivePool shouldn't be doing anything to halt the shutdown, especially if you're not using StableBit Cloud, as well. If you can still get a command prompt up, "shutdown -a" should abort the shutdown process. But I suspect that this isn't possible.

Just a note, any file operations that happen outside of the pool folder will require a remeasure to update the information. Not doing so means that any modifications are not reflected in the statistics and may not be duplicated or balanced properly/at all.

Unfortunately, this is a "special" folder in Windows, and is ... well, a royal PITA. To mess with anything in this folder, you need to take ownership and change the permissions on this folder. And unfortunately, that includes resolving conflicts. https://wiki.covecube.com/StableBit_DrivePool_Q5510455 or And you can safely delete the entire folder on the pool, since it's generally not used.

Unfortunately, shorting the name isn't likely something that is gonna happen. This ID is actually a GUID/UUID, and is used internally for ID'ing the poolpart. For reference: https://en.wikipedia.org/wiki/Universally_unique_identifier As for the 260 character path limit, depending on the software, you can bypass that by using the UNC naming for the folder. Eg, instead of "D:\PoolPart.xxxx\path", use "\\?\D:\PoolPart.xxxx\path". However, in general, you shouldn't use the poolpart folders directly. Doing so can cause issues/conflicts down the line. And the UNC path trick works for the pool itself too.

Correct, it doesn't effect realtime placement, unfortunately.

Yes, it is supported.

To clarify here, the main issue is with the signing of the driver for the pool driver. Unfortunately, this is something that is outside of our control, if we want to have signed drivers. The newer signing requirements/type is not compatible with older OS's, so to continue updating the drivers, it look like compatibility is broken with older versions of Windows. There isn't a lot that we can do about this, so maintaining backwards compatilbity isn't something we have control over. It may be posssible to use newer versions if test signing mode is enabled, but we DO NOT recommend this.

Volume equalization works between volumes on the same disk. You want "Drive Space Equalizer" specifically. It should be disabled by default.

Yeah, BSOD's shouldn't happen at all. If they are, and especially with covefs.sys, that's likely a bug or bad interaction. I think you already have, but opening a ticket is always the best bet in this type of case.

There are some driver changes recently, and it sounds like that may be the cause here. Rolling back is okay, but if you haven't already, open a ticket at https://stablebit.com/Contact, as BSODs shouldn't happen.

I'm glad to hear that, but I'm sorry to hear about the bad drive. As for StableBit Scanner not finding it, unfortunately, this is one of those "weird" issues that isn't straight forward to diagnose. Eg, it's not something that it may pick up. Slowing down the drive or other drives on the same controller wouldn't cause scans to fail, nor file system scans to fail. This is the sort of issue that you'd have to look for or to set up performance profiling for. And while that would be sure cool to have.... that stuff isn't exactly lightweight, and integrating it would be ... not simple.

I'm glad to hear it! The 1600 version is the last release version that appears to work on WHS2011, per my testing. So yes, I would recommend grabbing it from the link and installing that (the 1557 version will likely prompt for newer versions after installing it)

This can happen when a drive is having issues. But that isn't the sole cause of this. More than likely, this is a networking issue. Which you appear to have stumbled upon. That said, it may be worth disabling or fine tuning the network auto-tuning, as that usually causes issues. On both server and client, run: netsh interface tcp set global autotuninglevel=disabled or netsh interface tcp set global autotuninglevel=highlyrestricted And then reboot the system. Also, in the network adapter settings, jumbo frames can cause issues. And settings with "checksum" or "offload" can also cause issues.

uninstalling doesn't remove or reset the settings, so you should be fine with just uninstalling and reinstalling. Specifically, no need to delete the ProgramData folder. The "covefs failed to start" is the crux of the issue here, and is the driver for the pool. Without this, the pool can't run. And if it's not started/installed, then the service will generate a version mismatch, and stall out. Specifically this version should work: https://dl.covecube.com/DrivePoolWindows/release/download/StableBit.DrivePool_2.3.8.1600_x64_Release.exe

Have you checked the Event Viewer, and the "System" entry? A lot of the time, disk and controller errors do show up here. In fact, it's one of the first places I look when I suspect disk/hardware related issues (and yes, that includes in tickets). "logical block address" retries, ntfs errors, "resets on raid port" errors, and the like show up here. Also, for testing the disk/controller, the burst test may be useful for that (in StableBit Scanner).

2.3.5.1557 is probably the last version that will work. If not that one, then the release reight before it. (2.3.4.1542)

Namely, that Microsoft's support for the OS's ended October 2023, and we generally keep in lockstep with that. That's primarily due to the lack of updates and fixes that may negetively impact our software. It may continue to operate without issues, but we don't guarantee that.

I'm glad to hear it!

No worries. And StableBit Scanner should be translated, as well. If it's not, make sure that you're using this version, specifically: https://dl.covecube.com/ScannerWindows/release/download/StableBit.Scanner_2.6.11.4077_Release.exe

It might help to boost the priority: https://wiki.covecube.com/StableBit_DrivePool_2.x_Advanced_Settings Set the override value for "FileBalance_BackgroundIO" to false, and restart the service. And if that doesn't help, could you open a ticket at https://stablebit.com/Contact ?