Helldivers 2 problems, when installed on a DrivePool pool

[dooz]

Hello! Not quite sure if this deserves to be posted here, at all - or if it should only be on a support forum related to Helldivers 2 - but, I figured it wouldn't hurt to at least share what I've experienced, in case it helps others, somehow. (I'll try to share it with the Helldivers team, too, wherever they take support stuff)

In Helldivers 2, I seem to have quite a few bugs correlating to when it is installed on one of my DrivePool pools. The most apparent issues are graphical glitches that tend to result in stretched textures that spazz-out all over the screen or stretch bits of terrain across the entirety of the map, off to some infinitesimal point in the skybox. (If I am able, I might share some video or images of these glitches.) I also experience far more random crashes to desktop - with or without their error reporting dialog catching it.

The game is still fresh and occasionally prone to a hiccup or two by most players, once in a while. However, in my case, I noticed a significant decrease in the number of crashes - and all apparent graphical glitches - just by moving the Steam install of the game from the DrivePool pool to a standalone drive (not part of any pool). So: I had played about a week before the move, experiencing all sorts of problems; played for a couple weeks since the move, with little to no issues; and then, just today, decided to place it in a brand new pool, just to see if the problems returned. Indeed, by the second game, I experienced the familiar missing textures, rampant glitches, and eventually a crash. To me, this seems a definite correlation between (the majority of) my Helldivers 2 problems and DrivePool pools. This is not the first game I've seemed to have issues when installed on a DrivePool pool; but, this has been the most apparent case, yet.

I don't really know all that much about the potential reasons for this or how I could troubleshoot it further, so I won't try to waste time speculating. If there's anything I can try out to help identify the issue, do let me know! Some maybe-relevant pool settings:
- file/folder duplication is off (haven't tested with it "on" for the game files)
- tested problematic with "Bypass file system filters" both on and off
- read striping on (haven't tested with it "off" for the pool)
- the first pool consisted of 4 HDD and 2 SSD with SSD Optimization balancer enabled; while, the second pool consisted only of 2 SSD with default balancing.
- currently running latest version 2.3.6.1562 on Windows 10

[Christopher (Drashna)]

That's very odd.   I'm guessing it's something to do with the API that they're using, as I have a number of games installed to the pool, and don't experience any sort of issue like this. 

 

That said, if you could get logging of this, it would go a long way. 
https://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection

Eg, enable logging, reproduce the issue, then exit and stop the logging as soon as it occurs.   And note the exact time, if possible. 

Then open a ticket at https://stablebit.com/Contact and report/repost it there. 

[dooz]

Logged and submitted.
99% of time, pools have worked flawlessly for me for games (as far as I could tell), too. There's definitely something about the way this game does things that causes problems. Just, in hindsight, now I've got to wonder if I've hand-waved away an infrequent bug or two that may have been relevant to this, at all. 🤔 Something worth paying more attention to, on my end, for sure!
Anyway, hope it helps!

[Christopher (Drashna)]

Awesome, thanks. 

And my guess is that it's probably using an API in a way that is either wrong, or handled wrong by the pool.   Though, it could be something else, too. 

[haoma]

is there any update on this?

I'm interested in buying drivepool and i want to use it not just for storage but also gaming.

[Christopher (Drashna)]

I'd have to dig, but there have been a number of driver related fixes recently, so this may work better, now.

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

[Thronic]

Did you try turning read striping off?

[dooz]

I completely forgot about this issue until I made the mistake of moving some games around and placing Helldivers 2 back into a pool (consisting of 2 SSDs). I wanted to test the speed of launching it from the pool vs the previous drive. Upon launch and loading onto my ship, I was immediately met with a few of the glitchy, all-consuming, spinning-texture-entities like I shared in my video. As well, most of the ship had become a bright green hue! So, whatever the cause, the issue still persists. I still really don't experience this with any other game, that I can recall. :/

[dooz]

On 10/11/2024 at 3:40 PM, Thronic said:

Did you try turning read striping off?

While I did still have read-striping enabled, the directory that I placed HD2 into is set to unduplicated. From my understanding of the setting, read-striping only really kicks-in if you have some files duplicated to multiple drives in the pool, such that it can read the same file from both drives and hopefully read that file faster. If I understand correctly, then the setting wouldn't really have mattered in this case. :/

But, whether the setting is enabled for that pool or not, a different kind of "striping" will be happening here, certainly. That is, since it is set to unduplicated, some of the game's files will be placed on one physical drive or the other, at the mercy of pool balancing. Files used in HD2 will definitely be read from both drives - just not the "same" file at the same time, as would be the case in (my understanding of) read-striping. 

Could HD2 be having an issue with this part of it (where other games don't...)? Is it somehow getting-at the underlying, physical drive behind the pool and then trying to pivot or index to other files that may or may not be local to that physical disk? I'm just throwing darts, here - I have little idea how this stuff works or if that could be possible. :p It definitely seems like specifically HD2 is doing something wacky, or DrivePool is handling something wacky that they're doing in a wacky way, as Drashna said. 

From here, I guess a few tests I could try are: turn read-striping off; and, duplicate the files across the two drives, testing both with and without read-striping (which might test that "locality" theory, since both drives will have full copies of the game rather than partial copies). I suppose a pool with a single drive in it might be worth trying, too - in this case, if problems are experienced, then we could definitely rule out striping/duplicating, multiple drives, etc., and look hard at the way things are called and such!

I can't test more tonight, but I will try to attempt some of the above later this week or this weekend. (I'll try my best not to disappear for over a year, again!)

[Shane]

Hey, thanks for the update anyway! Could also try setting a File Placement rule to balance all of the HD2 files into just one of the pool's drives?

[dooz]

Heya! So yes, I tried a few different things.

• Moved HD2 onto a (2 x 2.5" 1TB SATA SSD) pool, folder was NOT duplicated. Read-striping disabled. Verified game files' integrity. Still glitchy.
• On the same pool, I set a File Placement rule to balance all the HD2 files onto one drive in the pool - as Shane suggested. Forced re-balance. Assigned a drive letter to both drives and verified that all files were indeed on one drive and that none were on the other. Verified game files' integrity. With or without read-striping enabled, it was still glitchy.
• Finally, I removed a (1 x 3.5" 2TB SATA HDD) drive from a pool, added it solo to a new pool, and moved HD2 to that new pool consisting of the singular drive. Verified game files' integrity. Still glitchy.

Between each step - before launching the game - I ensured the integrity of the game files via Steam. In all cases, I had glitches at some point when running the game. Usually, it would be immediately apparent upon loading into the ship.

Sometimes, on subsequent launches of the game, it wouldn't be immediately apparent. Maybe due to some kind of caching? In case there was some kind of caching going on, I opted to launch a separate game that used most of the memory in my system (overwriting any potential caching) before attempting to launch HD2 - which usually led to the glitches being immediately apparent upon launch and loading into the ship.

Here's another compilation of some of the glitches I usually saw upon loading into the ship, across a few different runs:

Quote

Ignore the stutter at the beginning! That was due to using software encoding rather than NVENC in OBS, for the first couple clips. I do not believe the issues with loading textures/models had an effect in this way. Transitions that fade to black separate different launches of the game. "Wipe" transitions indicate it is a different clip in the same run. As much as that matters (Not really). Among issues demonstrated here, there is:

• the Missing No. looking texture on the deck of the ship at the beginning.
• Greenification of everything.
• The all-consuming spinning entity returns.
• Glitches in the 2D textures shown in the outfitting menu.
• Many parts of the models for the weapons (separate run) not loading.
• Eagle-1 is invisible.
• The workers are all floating heads.

To show that I indeed had File Placement rules properly selected, in the one related attempt, here's a cropped screenshot of that menu:

Let me know if there's anything more you'd like me to try!

[Thronic]

Interesting...

And just to make sure, you have successfully run the game on a normal local drive?

Green artifacts due to bad gpus and/or outdated drivers is not unheard of.

[dooz]

13 hours ago, Thronic said:

Interesting...

And just to make sure, you have successfully run the game on a normal local drive?

Green artifacts due to bad gpus and/or outdated drivers is not unheard of.

Yes, for sure - playing from a non-Pool drive right now, actually. None of these bugs are present at all. 

As for GPUs / drivers, this has been tested on my end with: Nvidia's 1660ti and 2070, as well as AMD's 6800XT on all the latest drivers (after using DDU to uninstall drivers/etc. before switching between the mentioned cards). (I was looking to upgrade from my 1660ti to the 6800XT recently, but decided to return it (I just really don't need it for most games). Then, a buddy offered me his old 2070, so I'm using that now.) The issues present in the video from about a year ago, further up, were recorded on my 1660ti (which I still have and which the bugs still show up on), and the video I most recently shared is what you see running on the 2070

Edit: Temps-wise, everything is within reasonable temps. The cards have a ton of airflow, and I recently reapplied thermal paste and new thermal pads on the 2070 I'm currently using.

Edited August 25 by dooz
Extra info

[Shane]

On 8/25/2025 at 10:57 AM, dooz said:

Sometimes, on subsequent launches of the game, it wouldn't be immediately apparent. Maybe due to some kind of caching? In case there was some kind of caching going on, I opted to launch a separate game that used most of the memory in my system (overwriting any potential caching) before attempting to launch HD2 - which usually led to the glitches being immediately apparent upon launch and loading into the ship.

My wild guess is that HD2 isn't bothering to wait for and/or notice any messages from the pool device that its file requests are being queued, something like:

• HD2: "hey disk gimme this file NOW"
• Pool: "acknowledged, you-"
• HD2: "imma start reading!"
• Pool: "-are in the queue... done"

And on subsequent launches it's serendipitiously using the same, uncleared, memory ranges so it's finding the textures that finished loading the last time.

If you have StableBit's CloudDrive, I'd be curious whether either/both of

• putting HD2 on a local clouddrive residing directly on a physical drive
• putting HD2 on a local clouddrive residing in a pool

produces the same problem?

[Thronic]

This will be a hard thing to truly troubleshoot without Alex taking a special interest, even then it will be hard to know how exactly how the game is optimized.

Game could be trying to using direct access methods for optimization where shader cache is landing and/or using other filesystem bypasses. Could be using FileID for similar optimization reasons, which we now know DrivePool is using outside NTFS spec and inconsistent upon reboots and moves (which may happen a lot in games). File caching in games may not be very different from backup/synchronization software using same kinds of file access shortcuts.

As an example of how AAA game makers may take drastic steps to make their games optimized, I seem to remember not so long ago (cyberpunk?) crashed consistently on AMD Ryzen builds because of using assembly instructions directly for optimization - instructions that AMD had forgotten to include support for (in their 3600/3700 lineup?).  At the end of the day, DrivePool is a virtual file system originally made for relatively simple media serving. While being suitable for a lot of other things, we have learned it doesn't follow exact NTFS specs which equals pretty much YMMV for more intensive use.

Not sure you'll ever get a final answer to this. I'm a heavy gamer too and stay on dedicated drives for gaming.