Code Change Request

# 27685

Back to Code Changes

Technical Support
StableBit DrivePool
Windows 10 (64 bit)

* [Issue #27685] Added new dpcmd command: "delete-poolpart-reparse-points".
    - Deletes all reparse points under all pool part folders that are part of a pool. Reparse points are not allowed to exist in pool part folders.

Ok, here's what's going on:
  • By default, low priority pool I/O has 1 thread per pool in order to conserve system resources (the calling application specifies the priority required). But it turns out that this is not really the core of the problem here.
  • The DrivePool service is opening \SteamLibrary\SteamApps\common\Software Inc\Saves\$$ GSM_DATA $$ on the pool located at \Device\HarddiskVolume8
  • Covefs then tries to find the location of that pooled file.
  • It starts to probe the pool part \Device\HarddiskVolume3\PoolPart.f7ec51c3-5c5b-46e2-a871-99f7c56375ca\SteamLibrary\SteamApps\common\Software Inc\Saves\$$ GSM_DATA $$ to determine if the file exists.
  • This probe tries to open the file \OneDrive\Personal\savegames\GameSave Manager; Sync & Link\SoftwareInc\1\$$ GSM_DATA $$ on the pool \Device\HarddiskVolume8. Notice that that's not the file we're probing, and that it's now on the same pool that started the probe.
In short, opening a file on the pool causes a different file to be opened on the same pool. Since each pool only has 1 thread for low priority I/O, you have a deadlock.

But the real issue is that it seems that \Device\HarddiskVolume3\PoolPart.f7ec51c3-5c5b-46e2-a871-99f7c56375ca\SteamLibrary\SteamApps\common\Software Inc\Saves\$$ GSM_DATA $$ is a reparse point that points to the pool of which that pool part is part of. Thus, you've created a circular link.

Reparse points stored in PoolParts are not allowed and should never occur normally. DrivePool handles reparse points on the pool using its own separate data structures, and should never create reparse points in the PoolPart folders.

The folder in question seems to belong to the game save manager (

The solution is to get rid of that (and any other) reparse points in the PoolPart folders.

That dump looks like it's using covefs (or similar), that's a bit out of date. Try to upgrade to the latest BETA.

Also, I see the mozy.sys filter driver involved in the lockup.

If the update doesn't help, you may need to raise CoveFs_AsyncFindFilesLowPriorityThreads to something higher, like 3 (it's 1 by default now).

Let me know if the problem continues or if not, what fixed it.