All Activity

Thank you sir. I will proceed as planned. I'd much rather have one big drive than many small ones. And I know from past experience that Drivepool handles failed drives far far better than anything else out there.

Yes. I know at one point Chris mentions their pool had 26 drives in it, that was a while back. Glancing through the same thread another user's pool is 35 drives for example. I'm pretty sure I've seen screenshots of pools with ridiculous numbers of drives (40+) elsewhere in the forums but I can't remember where or exact numbers offhand. Theoretically DP can handle as many drives as Windows can support; the real limit is having good hardware. P.S. The trick with hardware RAID, zfs et al is you don't make one giant array, you make an array of smaller (three to six disks each) arrays. The pro is you can get things like parity protection, bitrot healing, stuff like that. The con is the extra micromanagement and how fiddly adding and removing disks can get. If you have a machine with good hardware RAID management you can have DrivePool do the pooling for all the small arrays so you can get the best of both worlds, but it's still something I'd only recommend planning out carefully.

I have a Supermicro chassis that hold 24 2.5" drives. It's populated with 24 900GB drives. Is Drivepool suitable for a 24 drive pool? From what I've read, neither hardware RAID nor zfs is. TIA

If the drive is sufficiently bad, it may not be removable via the UI options while it's still physically connected to the machine. If you have duplication enabled for its content you can still physically remove it and then remove it in the UI, and DrivePool will reduplicate the content from and to the remaining disks. If you don't have duplication enabled for its content and don't want to restore from a backup you could manually copy that content to a spare or new disk (how well this works will of course depend on how it's going bad) before physically removing it so that you can reinsert the content back into the pool afterwards.

This drive is reportedly going back according to both Stablebit Scanner and the BIOS. I'm trying to remove it from the pool, but it says 45% almost instantly and is otherwise stuck. The DrivePool interface shows no reads or writes. I tried the "Force Removal of Damaged Drive" and this is the result. Ideas?

I would suggest opening a ticket with StableBit with what's happened and your workaround, hopefully they can both resolve it permanently for you and fix whatever the underlying cause is. Tagging @Christopher (Drashna) in the meantime.

So I've 'fixed' this issue somewhat manually. Still not sure what's causing it. Every time I boot up my computer, DP UI shows no disks. I have to run this in powershell: $dpcmd = "C:\Program Files\StableBit\DrivePool\dpcmd.exe" $tempLetter = "D" $diskNumbers = @(0, 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 15) foreach ($diskNum in $diskNumbers) { # Get the largest Basic partition with no drive letter on this disk $part = Get-Partition -DiskNumber $diskNum | Where-Object { $_.Type -eq "Basic" -and [string]$_.DriveLetter -eq "" } | Sort-Object Size -Descending | Select-Object -First 1 if ($null -eq $part) { Write-Host "Disk $diskNum - No eligible partition found, skipping." continue } Write-Host "Disk $diskNum - Partition $($part.PartitionNumber) ($([math]::Round($part.Size / 1GB, 1)) GB) - Assigning $tempLetter`:\" $part | Add-PartitionAccessPath -AccessPath "$tempLetter`:\" -ErrorAction SilentlyContinue Start-Sleep -Seconds 2 Write-Host "Disk $diskNum - Hinting DrivePool..." & $dpcmd hint-poolpart "$tempLetter`:\" Start-Sleep -Seconds 1 Write-Host "Disk $diskNum - Removing $tempLetter`:\" $part | Remove-PartitionAccessPath -AccessPath "$tempLetter`:\" -ErrorAction SilentlyContinue Write-Host "Disk $diskNum - Done." Write-Host "" } Write-Host "All disks processed!" This goes through and mounts the drive letter D:\ to the largest empty partition on each drive that is supposed to be pooled, hints drivepool of that drive, then unmounts the letter and moves on. I have to run this every boot in order for my pool to reappear. Not the worst thing in the world, but definitely annoying. It can take 20-30 minutes after running the script for the 'Measuring' step to be complete.

Hmm. What happens if you run "dpcmd unignore-poolpart poolpartfullpath" for one of the "missing" disks? For example if you mounted one of the "missing" disks under the drive letter "M" you'd run something like (replacing the poolpart's folder name appropriately): dpcmd unignore-poolpart m:\poolpart.12345678-90ab-cdef-1234-567890abcdef Or if you had all of your poolpart disks mounted as folders under a physical disk instead of having drive letters of their own, it'd be something like: dpcmd unignore-poolpart e:\mounts\disk05\poolpart.12345678-90ab-cdef-1234-567890abcdef Does that disk come back? Just wondering if the unexpected restart in the middle of adding the new disks mangled the pool's part tagging.

Hi all, hoping someone can help me track down why my pool vanished after a reboot today. Setup: - StableBit DrivePool 2.3.13.1687 - Windows 11 (10.0.26200.0) - ~13 drives in the pool - Pool mounted as Z:\ What happened: Booted up today and DrivePool showed no pool at all — just "Create a New Pool" with 3 non-pooled disks (boot drive, game drive, and one unrelated drive). Restarting the service and rebooting did not help. What I've verified: - PoolPart folders are intact on the drives (confirmed visually) - CoveFs is running (STATE: 4 RUNNING, WIN32_EXIT_CODE: 0) - All physical drives are visible to Windows via Get-PhysicalDisk (see below) - The ProgramData\StableBit DrivePool\Service\Store folder is intact and has 99 files modified today - Service log shows a clean startup with no errors - `dpcmd list-poolparts Z:\ 1` shows only 1 of 13 pool parts mounted (the WD 6TB, Device 1, HarddiskVolume9) - `dpcmd refresh-all-poolparts` did not recover the missing disks - Ran `dpcmd hint-poolpart` on all 17 candidate volumes from mountvol output — no effect - Restarted service after hints — no change - The DrivePool UI does show all 13 pool slots as "Disk is missing" after interacting with the UI, so the database is intact **Get-PhysicalDisk output:** ``` DeviceId FriendlyName Size 0 TOSHIBA DT01ACA100 1000204886016 1 WDC WD6003FZBX-00K5WB0 6001175126016 2 WDC WD101EFBX-68B0AN0 10000831348736 3 WDC WD10JPVX-75JC3T0 1000204886016 4 TOSHIBA MQ04ABF100 1000204886016 5 WDC WD101EFBX-68B0AN0 10000831348736 6 Samsung SSD 990 EVO Plus 2TB 2000398934016 7 Samsung SSD 970 EVO 1TB 1000204886016 8 ASMT 2115 500107862016 9 ASMT 2115 500107862016 10 ASMT 2115 500107862016 11 ASMT 2115 1000204886016 12 ASMT 2115 2000398934016 13 ASMT 2115 1000204886016 14 ASMT 2115 500107862016 15 ASMT 2115 500107862016 16 COVECUBE CoveFsDisk_____ 2199023255552 ``` **dpcmd list-poolparts Z:\ 1 output:** ``` Pool ID '97e2ad00-8f62-4104-84b4-c351ebc5f756': - '\\?\GLOBALROOT\Device\HarddiskVolume9\PoolPart.ceaa3e43-7485-45c9-9d91-9e0e79d02d63' [Device 1] - Volume Size: 6,000,636,588,032 B (5.46 TB) - Used: 4,811,055,149,056 B (4.38 TB) - Free: 1,189,581,438,976 B (1.08 TB) ``` Was working fine for months. What changed today: I removed 2 drives from the pool just fine. I then added 2 new drives to my machine, and those were being scanned. Not added to the pool quite yet. I restarted my computer during this, and poof If I assign a drive letter, the UI goes from "Disk 5" Missing, to "Disk D:" Missing. So it can see the drives in a sense. Only that one disk is mapping. The other 12 pool members are physically present and visible to Windows but DrivePool can't attach to them. Data is safe, I just can't access the pool. Any ideas what's gone wrong here and how to force the re-association?

I fixed the problem. All is good now. I had a permission problem. I had to reorder the permissions on each root folder. I gave them full control and the error went away. I can now see the file list under file protection also now. Thanks.

It's been a miinute since I've posted here but my server has been running flawlessly for several years. We recently had a house fire & lost everything. So I have purchased a new computer and am trying to recreate my server. Of course this new computer is running Windows 11. With 1 drive added everything is running fine. I can hit the balancing tab to see the balancers and have no errors. But as soon as I add a 2nd drive I get the error when I hit the balancing tab "unable to enumerate folder". Any help would be appreciated. I am running the latest version of Drive Pool. Thanks Phillip Hury

Thanks for thinking about this, but it doesn't really sound like there's a way to make this work cleanly for now. I'm going to make the two SSDs into their own pool with their own drive letter. Having multiple mounted pools isn't as tidy as I'd like, but it'll have to do.

The scanner plugin should since "Unless the drive is being emptied" is still ticked. The optimizer plugin I'm unsure of.

My concern with that was whether that would mean that the balancing plug-ins would be ignored entirely for any folder that's affected by a rule (which would be everything due to the 2nd placement rule). Would the scanner and SSD optimizer plugins still do what they should, considering the entire pool (minus the SSD) is in a placement rule?

A1. It looks like it's based on the oldest scanned block. If you expand the drive (the + sign) it shows the sector scanning and you can see the date and time of when that happened to the upper right of the grid map, which at least on mine matches up. A2. The tooltip mentions that it's "only when disks have to be re-checked" and the tooltip for "unless disk scans are past due by" mentions it won't do anything until the disk has already been scanned at least once? A3. Could be Windows-related; I've had Windows insist a drive is in use even when Resource Monitor is saying there aren't any files open? Welcome to DrivePool and Scanner!

I think un-ticking "Balancing -> Settings -> File placement rules respect real-time file placement limits set by the balancing plug-ins." is what's needed? You want the VMs to be sorted into the 4TB SSD by the File placement rules more than you want them to be cached into and emptied out of the 1TB SSD by the SSD Optimizer plug-in, and perhaps without that un-ticking the SSD Optimizer might be ignoring the File placement rules when it's emptying the "SSD" disk into the "Archive" disks?

So, I'm fresh to Drivepool and Drive Scanner, and I run into a few things that I don't understand. I hope someone can explain them to me. Background: I recently build an AM4 home server, using 8x 4 TB drives (all leftovers, of which some of very questionable heritage, and some are even SMR's, brrr). Hardware: AM4 Asus Pro mainboard / Ryzen 5 3500X / Axagon PCES-SA6 / 16 GB RAM / HDD 9x HDD / 1x NVME / 1x SSD Software: Windows 11 / Drivepool / Drivescanner / HDD Sentinel Other software on the same machine: SqueezeBox (Lyrion) Server / Plex I noticed a few things, and perhaps I don't understand how it exactly works. 1. In the Drivescanner window, it shows how many days ago the last scan took place. I have different periods set for filesystem scans and sector scans. What is exactly shown on that page? The last sector scan, or just any scan activity? 2. When I set in settings 'only perform within this window' it doesn't seem to matter whatever I set as 'unless disk scans are past due by xxx days'. It just never starts scanning, unless I use 'perform work at any time'. A bug, or something I don't understand? (Probably the latter 🙂 ) 3. Under throttling I use 'do not interfere' with 'high sensitivity' which is ok. I was just wondering why 'scan using background' would never trigger a scan, even when there's nto a single user or other application (but the generic services) actively accessing any of the drives. Again, I'm a newby with Drivepool and Drivescanner...

The rules in my edit to the initial post did not work. I noticed that nothing was being moved to the SSD, so I tried pausing the service and manually moving the data to the SSD. I then let DP recheck/rebalance overnight. By morning, the data I'd moved to the SSD had been moved out of the SSD and back to the HDDs. Clearly something is off with my rules. I've moved the 1TB drive to be used as an SSD cache named `PooledCache01`, and have added a 4TB drive `PooledSSD01` that I'd like to use for the VMs. The total size of the VMs folder is currently ~1TB so it would only take ~25% of the 4TB drive, so free space is not the issue. Any advice would be welcome.

I have a 100TB pool with HDDs mounted as `D:\`. I recently added a 1TB SSD, and I would like to set it to store my virtual machines (located in `D:\VMs`). I set a placement rule to store the VMs folder (which needs fast access) only on the SSD drive, but I can't figure out how to set the SSD drive to store only the VMs folder (and nothing else). Is there a way to limit a drive to only store specific folders? EDIT: I realized I'd only tried to get this to work with folder rules, not pattern-based rules. So I'm trying the following two rules: /VMS/* -> only SSD drive /* -> all drives except SSD, checked "When a drive is added to the pool, files matching this rule should be placed on the drive." Thoughts on whether that'll work as I expect?

WinDbg: ExtensionGallery settings after reading 'SOFTWARE\Microsoft\Debug Engine' registry: ExtensionGallery ExtensionRepository: Implicit ************* Preparing the environment for Debugger Extensions Gallery repositories ************** ExtensionRepository : Implicit UseExperimentalFeatureForNugetShare : true AllowNugetExeUpdate : true NonInteractiveNuget : true AllowNugetMSCredentialProviderInstall : true AllowParallelInitializationOfLocalRepositories : true EnableRedirectToChakraJsProvider : false -- Configuring repositories ----> Repository : LocalInstalled, Enabled: true ----> Repository : UserExtensions, Enabled: true >>>>>>>>>>>>> Preparing the environment for Debugger Extensions Gallery repositories completed, duration 0.000 seconds ************* Waiting for Debugger Extensions Gallery to Initialize ************** >>>>>>>>>>>>> Waiting for Debugger Extensions Gallery to Initialize completed, duration 0.015 seconds ----> Repository : UserExtensions, Enabled: true, Packages count: 0 ----> Repository : LocalInstalled, Enabled: true, Packages count: 46 Microsoft (R) Windows Debugger Version 10.0.29547.1002 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Windows\MEMORY.DMP] Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available. Symbol search path is: srv* Executable search path is: Windows 10 Kernel Version 19041 MP (24 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Edition build lab: 19041.1.amd64fre.vb_release.191206-1406 Kernel base = 0xfffff803`7ce00000 PsLoadedModuleList = 0xfffff803`7da2a8c0 Debug session time: Sat Apr 25 01:53:16.210 2026 (UTC + 2:00) System Uptime: 8 days 7:56:57.750 Loading Kernel Symbols ............................................................... ................................................................ ................................................................ ...................................................... Loading User Symbols PEB is paged out (Peb.Ldr = 000000fd`b29ba018). Type ".hh dbgerr001" for details Loading unloaded module list ............................. For analysis of this file, run !analyze -v nt!KeBugCheckEx: fffff803`7d1fdef0 48894c2408 mov qword ptr [rsp+8],rcx ss:ffffb30b`c77b3080=0000000000000044 0: kd> !analyze -v Loading Kernel Symbols ............................................................... ................................................................ ................................................................ ...................................................... Loading User Symbols PEB is paged out (Peb.Ldr = 000000fd`b29ba018). Type ".hh dbgerr001" for details Loading unloaded module list ............................. ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* MULTIPLE_IRP_COMPLETE_REQUESTS (44) A driver has requested that an IRP be completed (IoCompleteRequest()), but the packet has already been completed. This is a tough bug to find because the easiest case, a driver actually attempted to complete its own packet twice, is generally not what happened. Rather, two separate drivers each believe that they own the packet, and each attempts to complete it. The first actually works, and the second fails. Tracking down which drivers in the system actually did this is difficult, generally because the trails of the first driver have been covered by the second. However, the driver stack for the current request can be found by examining the DeviceObject fields in each of the stack locations. Arguments: Arg1: ffff9108203db720, Address of the IRP Arg2: 0000000000001269 Arg3: 0000000000000000 Arg4: 0000000000000000 Debugging Details: ------------------ Unable to load image \??\C:\Windows\system32\drivers\covefs.sys, Win32 error 0n2 *** WARNING: Check Image - Checksum mismatch - Dump: 0xeb2e, File: 0xcaa1 - C:\ProgramData\Dbg\sym\hal.dll\1A7BE8E96000\hal.dll KEY_VALUES_STRING: 1 Key : Analysis.CPU.mSec Value: 1250 Key : Analysis.Elapsed.mSec Value: 6203 Key : Analysis.IO.Other.Mb Value: 10 Key : Analysis.IO.Read.Mb Value: 1 Key : Analysis.IO.Write.Mb Value: 25 Key : Analysis.Init.CPU.mSec Value: 671 Key : Analysis.Init.Elapsed.mSec Value: 30723 Key : Analysis.Memory.CommitPeak.Mb Value: 90 Key : Analysis.Version.DbgEng Value: 10.0.29547.1002 Key : Analysis.Version.Description Value: 10.2602.27.2 amd64fre Key : Analysis.Version.Ext Value: 1.2602.27.2 Key : Bugcheck.Code.KiBugCheckData Value: 0x44 Key : Bugcheck.Code.LegacyAPI Value: 0x44 Key : Bugcheck.Code.TargetModel Value: 0x44 Key : Failure.Bucket Value: 0x44_nt!IofCompleteRequest Key : Failure.Hash Value: {10bf0b0b-4caf-2e9c-30ae-ac07c3e144ed} Key : Hypervisor.Enlightenments.Value Value: 77057948 Key : Hypervisor.Enlightenments.ValueHex Value: 0x497cf9c Key : Hypervisor.Flags.AnyHypervisorPresent Value: 1 Key : Hypervisor.Flags.ApicEnlightened Value: 1 Key : Hypervisor.Flags.ApicVirtualizationAvailable Value: 0 Key : Hypervisor.Flags.AsyncMemoryHint Value: 0 Key : Hypervisor.Flags.CoreSchedulerRequested Value: 0 Key : Hypervisor.Flags.CpuManager Value: 1 Key : Hypervisor.Flags.DeprecateAutoEoi Value: 0 Key : Hypervisor.Flags.DynamicCpuDisabled Value: 1 Key : Hypervisor.Flags.Epf Value: 0 Key : Hypervisor.Flags.ExtendedProcessorMasks Value: 1 Key : Hypervisor.Flags.HardwareMbecAvailable Value: 1 Key : Hypervisor.Flags.MaxBankNumber Value: 0 Key : Hypervisor.Flags.MemoryZeroingControl Value: 0 Key : Hypervisor.Flags.NoExtendedRangeFlush Value: 0 Key : Hypervisor.Flags.NoNonArchCoreSharing Value: 1 Key : Hypervisor.Flags.Phase0InitDone Value: 1 Key : Hypervisor.Flags.PowerSchedulerQos Value: 0 Key : Hypervisor.Flags.RootScheduler Value: 0 Key : Hypervisor.Flags.SynicAvailable Value: 1 Key : Hypervisor.Flags.UseQpcBias Value: 0 Key : Hypervisor.Flags.Value Value: 4853999 Key : Hypervisor.Flags.ValueHex Value: 0x4a10ef Key : Hypervisor.Flags.VpAssistPage Value: 1 Key : Hypervisor.Flags.VsmAvailable Value: 1 Key : Hypervisor.RootFlags.AccessStats Value: 1 Key : Hypervisor.RootFlags.CrashdumpEnlightened Value: 1 Key : Hypervisor.RootFlags.CreateVirtualProcessor Value: 1 Key : Hypervisor.RootFlags.DisableHyperthreading Value: 0 Key : Hypervisor.RootFlags.HostTimelineSync Value: 1 Key : Hypervisor.RootFlags.HypervisorDebuggingEnabled Value: 0 Key : Hypervisor.RootFlags.IsHyperV Value: 1 Key : Hypervisor.RootFlags.LivedumpEnlightened Value: 1 Key : Hypervisor.RootFlags.MapDeviceInterrupt Value: 1 Key : Hypervisor.RootFlags.MceEnlightened Value: 1 Key : Hypervisor.RootFlags.Nested Value: 0 Key : Hypervisor.RootFlags.StartLogicalProcessor Value: 1 Key : Hypervisor.RootFlags.Value Value: 1015 Key : Hypervisor.RootFlags.ValueHex Value: 0x3f7 Key : SecureKernel.HalpHvciEnabled Value: 0 Key : WER.OS.Branch Value: vb_release Key : WER.OS.Version Value: 10.0.19041.1 Key : WER.System.BIOSRevision Value: 5.35.0.0 BUGCHECK_CODE: 44 BUGCHECK_P1: ffff9108203db720 BUGCHECK_P2: 1269 BUGCHECK_P3: 0 BUGCHECK_P4: 0 FILE_IN_CAB: MEMORY.DMP FAULTING_THREAD: ffff9107fd0d55c0 IRP_ADDRESS: ffff9108203db720 PROCESS_NAME: qbittorrent.exe STACK_TEXT: ffffb30b`c77b3078 fffff803`7d044a5e : 00000000`00000044 ffff9108`203db720 00000000`00001269 00000000`00000000 : nt!KeBugCheckEx ffffb30b`c77b3080 fffff803`7d0434a7 : ffff9108`203db720 ffffdf0a`71890901 ffffdf0a`92e03790 ffffdf0a`718909c0 : nt!IopfCompleteRequest+0x159e ffffb30b`c77b3180 fffff803`7d1f0a11 : 00000000`00000018 ffffdf0a`92e03790 ffffdf0a`92e03790 ffff9108`203db720 : nt!IofCompleteRequest+0x17 ffffb30b`c77b31b0 fffff803`7d1553aa : ffffdf0a`92e037c8 00000000`00000000 ffff9107`cf0b8e00 ffffdf0a`92e03790 : nt!FsRtlpRemoveAndCompleteRHIrp+0x159 ffffb30b`c77b31f0 fffff803`7d4b873e : 00000000`00000000 ffff9107`cf0b8e50 ffff9107`cf0b8ab0 ffffdf0a`00000000 : nt!FsRtlpOplockBreakByCacheFlags+0x59a ffffb30b`c77b32c0 fffff803`7bbf43c8 : 00000000`00000001 ffff9107`cf0b8a00 ffff9107`c0000043 ffff9108`1cbe12c8 : nt!FsRtlOplockBreakH+0x11e ffffb30b`c77b3380 fffff803`7bbf3e67 : 00000000`00000080 00000000`00000008 ffffb30b`c77b3c20 ffffdf0a`000000e8 : Ntfs!NtfsOpenExistingAttr+0x2c8 ffffb30b`c77b3440 fffff803`7bbf267a : ffffb30b`c77b3c20 ffffdf08`62a8db40 ffffdf0a`7a9e0660 ffffdf0a`7a9e0660 : Ntfs!NtfsOpenAttributeInExistingFile+0xae7 ffffb30b`c77b3630 fffff803`7bbe630f : ffff9108`1cbe12c8 ffff9107`d7e9e4f0 ffffdf08`3a11a7c0 ffffdf0a`84465c01 : Ntfs!NtfsOpenExistingPrefixFcb+0x22a ffffb30b`c77b3740 fffff803`7bbe7210 : ffff9108`1cbe12c8 ffff9107`cf0b8ab0 00000000`00000003 ffffb30b`c77b39e0 : Ntfs!NtfsFindStartingNode+0x3ff ffffb30b`c77b3830 fffff803`7bbe26bb : ffff9107`cf0b8ab0 ffffb30b`c77b3c20 ffff9107`cf0b8ab0 00000000`00000000 : Ntfs!NtfsCommonCreate+0x580 ffffb30b`c77b3b10 fffff803`7d151a25 : ffff9107`d7e9d030 ffff9107`cf0b8ab0 ffffb30b`c77b3e00 ffff9108`2c0072a0 : Ntfs!NtfsFsdCreate+0x1db ffffb30b`c77b3d90 fffff803`7ae8710f : ffff9108`2c007300 ffffb30b`c77b3e80 ffffb30b`c77b3e89 fffff803`7ae85f7a : nt!IofCallDriver+0x55 ffffb30b`c77b3dd0 fffff803`7aeb9ee4 : ffffb30b`c77b3e80 ffff9108`2c0072f8 ffff9107`d5fc77d0 00000000`00000000 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28f ffffb30b`c77b3e40 fffff803`7d151a25 : 00000000`00000000 ffff9107`cb8ecc40 00000000`00000000 00000000`00000000 : FLTMGR!FltpCreate+0x324 ffffb30b`c77b3ef0 fffff803`7d1538e4 : ffff9108`2c0072a0 fffff803`7d7b418e ffff9107`cb8ecc40 fffff803`7d153513 : nt!IofCallDriver+0x55 ffffb30b`c77b3f30 fffff803`7d502109 : ffffb30b`c77b41e0 ffff9107`cb8ecc40 ffff9108`2c007338 00000000`00000240 : nt!IoCallDriverWithTracing+0x34 ffffb30b`c77b3f80 fffff803`7d4f5037 : ffff9107`cb8ecc40 ffff9107`cb8ecc10 ffff9107`d280b6a0 ffff9107`b91faa00 : nt!IopParseDevice+0x11a9 ffffb30b`c77b40e0 fffff803`7d455eca : ffff9107`d280b601 ffffb30b`c77b4348 ffff9108`00000240 ffff9107`b91faae0 : nt!ObpLookupObjectName+0x1117 ffffb30b`c77b42b0 fffff803`7d40bfd1 : 00000000`00000000 ffffb30b`c77b4778 ffffb30b`c77b46f8 00000000`00000000 : nt!ObOpenObjectByNameEx+0x1fa ffffb30b`c77b43e0 fffff803`7d40b38d : ffffb30b`c77b4618 ffffb30b`00010080 ffffb30b`c77b4778 ffffb30b`c77b46f8 : nt!IopCreateFile+0xb11 ffffb30b`c77b4490 fffff803`c55d998d : 00000000`00000001 00000000`00000008 00000000`00000000 00000000`00000001 : nt!IoCreateFileEx+0x11d ffffb30b`c77b4530 fffff803`c55db592 : 00000000`00000000 fffff803`c5604d70 00000000`00000000 ffff9107`d7fb29f0 : covefs+0x998d ffffb30b`c77b4840 fffff803`7d12a078 : 00000000`00000008 ffff9107`cf069010 ffff9107`00000000 00000000`01200040 : covefs+0xb592 ffffb30b`c77b4910 fffff803`7d0d3375 : fffff803`c55db4d0 ffffb30b`c77b4b50 00000000`00000000 00000000`01200000 : nt!KeExpandKernelStackAndCalloutInternal+0x78 ffffb30b`c77b4980 fffff803`c55dd092 : ffff9107`d7fb2990 00000000`00000000 ffffffff`ee1e5d00 ffff9107`d7fb2010 : nt!KeExpandKernelStackAndCallout+0x15 ffffb30b`c77b49c0 fffff803`7d151a25 : ffff9107`d7fb1040 ffff9107`e16cd2a0 ffffb30b`c77b4d00 ffff9108`2c004600 : covefs+0xd092 ffffb30b`c77b4c80 fffff803`7ae8710f : ffff9108`2c004700 ffffb30b`c77b4d70 ffffb30b`c77b4d79 fffff803`7ae85f7a : nt!IofCallDriver+0x55 ffffb30b`c77b4cc0 fffff803`7aeb9ee4 : ffffb30b`c77b4d70 ffff9108`2c004738 ffff9107`d2440da0 00000000`00000000 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28f ffffb30b`c77b4d30 fffff803`7d151a25 : ffffdf08`00000000 ffff9107`d55f3c00 00000000`00000000 00000000`00000000 : FLTMGR!FltpCreate+0x324 ffffb30b`c77b4de0 fffff803`7d1538e4 : ffff9108`2c0046e0 fffff803`7d7b418e ffff9107`d55f3c00 fffff803`7d153513 : nt!IofCallDriver+0x55 ffffb30b`c77b4e20 fffff803`7d502109 : ffffb30b`c77b50d0 ffff9107`d55f3c00 ffff9108`2c004778 00000000`00000040 : nt!IoCallDriverWithTracing+0x34 ffffb30b`c77b4e70 fffff803`7d4f5037 : ffff9107`d55f3c00 ffff9107`d55f3bd0 ffff9108`38080550 ffffdf08`387af301 : nt!IopParseDevice+0x11a9 ffffb30b`c77b4fd0 fffff803`7d455eca : ffff9108`38080501 ffffb30b`c77b5238 ffff9107`00000040 ffff9107`b91faae0 : nt!ObpLookupObjectName+0x1117 ffffb30b`c77b51a0 fffff803`7d40bfd1 : 00000000`00000000 000000fd`b2eff408 000000fd`b2eff3c8 00000000`00000000 : nt!ObOpenObjectByNameEx+0x1fa ffffb30b`c77b52d0 fffff803`7d40b418 : 000000fd`b2eff498 ffffb30b`00010080 000000fd`b2eff408 000000fd`b2eff3c8 : nt!IopCreateFile+0xb11 ffffb30b`c77b5380 fffff803`7d21270b : 00000000`00000000 fffff803`7d3aa427 ffff9107`fd0d55c0 00000000`00000000 : nt!NtOpenFile+0x58 ffffb30b`c77b5410 00007ffb`fbe8dcb4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExitPico+0x41f 000000fd`b2eff388 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffb`fbe8dcb4 SYMBOL_NAME: nt!IofCompleteRequest+17 MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe STACK_COMMAND: .process /r /p 0xffff9107deacf080; .thread /r /p 0xffff9107fd0d55c0 ; kb BUCKET_ID_FUNC_OFFSET: 17 FAILURE_BUCKET_ID: 0x44_nt!IofCompleteRequest OS_VERSION: 10.0.19041.1 BUILDLAB_STR: vb_release OSPLATFORM_TYPE: x64 OSNAME: Windows 10 FAILURE_ID_HASH: {10bf0b0b-4caf-2e9c-30ae-ac07c3e144ed} Followup: MachineOwner ---------

I just experienced my 6th crash (over ~1 year period) directly attributed to CoveFS driver. To devs: please improve the stability of driver. I will only use the StableBit Troubleshooter if I can review the information it sends before sending it. Otherwise, without confirmation of complete data anonymity, I will not use it. Here is the crash dump: Crash Dump Analysis -------------------------------------------------------------------------------- Crash dumps are enabled on your computer. Crash dump directories: C:\Windows C:\Windows\Minidump On Sat 25/04/2026 01:53:16 your computer crashed or a problem was reported Crash dump file: C:\Windows\Minidump\042526-117328-01.dmp (Minidump) Bugcheck code: 0x44(0xFFFF9108203DB720, 0x1269, 0x0, 0x0) Bugcheck name: MULTIPLE_IRP_COMPLETE_REQUESTS Bug check description: This indicates that a driver has tried to requested an IRP be completed that is already complete. Analysis: This is a typical software problem. Most likely this is caused by a bug in a driver. On Sat 25/04/2026 01:53:16 your computer crashed or a problem was reported Crash dump file: C:\Windows\MEMORY.DMP (Kernel memory dump) Bugcheck code: 0x44(0xFFFF9108203DB720, 0x1269, 0x0, 0x0) Bugcheck name: MULTIPLE_IRP_COMPLETE_REQUESTS Driver or module in which error occurred: covefs.sys (covefs+0x998D) File path: C:\Windows\system32\drivers\covefs.sys Description: CoveFS File System Driver Product: CoveFS Company: Covecube Inc. Bug check description: This indicates that a driver has tried to requested an IRP be completed that is already complete. Analysis: This is a typical software problem. Most likely this is caused by a bug in a driver. A third party driver was identified as the probable root cause of this system error. It is suggested you look for an update for the following driver: covefs.sys (CoveFS File System Driver, Covecube Inc.). Google query: covefs Covecube Inc. MULTIPLE_IRP_COMPLETE_REQUESTS

Yeah, that looks a wrapping error. And yes, there should be a "submit to Stablebit" option. Either way, would be a good idea to hopen a ticket at https://stablebit.com/Contact, at the very least so we can handle this better.

Disabling write caching on the drives will make them VERY slow. As for explorer vs StableBit DrivePool, balancing and duplication and similar tasks are ran in a background priority. This can cause the transfers to be slower, especially if there is activity on the pool. But I'm glad to hear that this was a simple fix!

That's ... not uncommon. As a smaller vendor, false positives are much more common. Though testing this myself, i don't see it blocking the UI. So likely, the false positive has been resolved already?

That's ... a lot of symlinks. Though, there shouldn't be an issue with doing that. Are you on the latest version? That said, if you ran reproduce this: https://wiki.covecube.com/System_Freeze and open a ticket at https://stablebit.com/Contact