Fatal program exit requested in fmodstudio.dll (2.02.06)

Hey! We just got a report of a crash in fmodstudio.dll (2.02.06) that bypassed our in-game crash reporter. It appears to be a __fastfail(FAST_FAIL_FATAL_APP_EXIT):

00007FFB1495CFD8  mov         ecx,7  
00007FFB1495CFDD  int         29h  

This seems to happen on FMOD’s own thread:

The report comes from a long-time beta tester, and has only occurred once so far, so I can’t easily verify if upgrading to a new version of FMOD would resolve it.

Any ideas for how to proceed? I can’t do much without symbols, but I can share the minidump if that’s useful :slight_smile:

Thanks!

Not much to go off here, but a minidump would certainly be useful. If you could please upload the minidump to your FMOD Profile I will take a look.

Thanks for the quick reply! :two_hearts: I’ve uploaded the minidump. Please let me know if there’s anything else that would be useful (bank files, etc.)

Thank you for sending those over- there’s not a whole lot of memory in this capture so it’s difficult to see what’s going wrong, but it looks like an audio resource that was in use has been deleted somehow. There are a few scenarios I can think of where this might happen:

Can you please take a look through your source code and tell me if there are any instances of programmer sound callbacks or use of FMOD_OPENMEMORY_POINT, and also tell me if your FMOD Studio project settings are using either of the “Separate Metadata and Assets” or “Including Referenced Events in Banks” options?

Thanks for digging into it! :green_heart:
Let’s see… here’s the project build settings for starters:

So we do split the metadata, but we don’t skip including referenced events in banks.

As for what we do with FMOD in our codebase:

  • We don’t use programmer sounds.
  • We don’t use FMOD_OPENMEMORY_POINT (in fact, we don’t use any Sounds or Streams at all - we operate on Events).
  • We don’t unload any banks, even on shutdown.

It’s probably easier to describe what we do with FMOD than what we don’t do, as our uses are rather simple:

  • We interface with the C API (via a Rust binding, as our game is written in Rust)
  • We initialize FMOD Studio very early in the game, and we do so asynchronously with the rest of the game, on a separate thread. We use FMOD_STUDIO_INIT_NORMAL and FMOD_INIT_NORMAL | FMOD_INIT_3D_RIGHTHANDED
  • We pre-load Master.strings.bank, Master.bank, UI.bank, UI.assets.bank, including their sample data, and proceed to use them in the loading screen.
    • (we use FMOD_STUDIO_LOAD_BANK_NORMAL everywhere)
  • Meanwhile we continue loading all the remaining banks and sample data while showing the loading screen.
  • Once everything is loaded, we proceed to gameplay, where we use pretty much just events, parameters, and a single listener.
  • We call FMOD_Studio_System_Update once per frame from our multi-threaded task system (the loading screen does the same).
    • I think there’s one frame when there’s a slim chance that we might call FMOD_Studio_System_Update from both the loading screen and the game at the same time. No idea if that would cause any issues, but I figured I should mention it anyway.
  • We let the OS clean everything up on shutdown.

So all in all, we don’t do anything too fancy, but maybe we push a bit more on threading than many titles. Rust makes that safe & easy but we could still have messed up somewhere of course.

You’ve indicated that this crash might happen upon bank unloading - but could it happen due to the banks not having finished loading, and us trying to create events referencing those banks? FWIW I’ve just tried adding some sleeps to the async bank loading code, and the game still patiently waited for it all to finish.

Sorry that the minidump didn’t have too much info in it. I’ll keep my eyes peeled on any other instances of this, and if we can get a repro, I’ll get a minidump with more info.