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 solution is to get rid of that (and any other) reparse points in the PoolPart folders.