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 
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! 
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! 
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.
Sorry for the delayed response, and thank you for the additional context.
It certainly sounds like it would be related to an incomplete load state between metadata and asset banks. I tried freezing the sample loading thread to see what happens when you try to play an event when a bank hasn’t finished loading, but I couldn’t reproduce any crashes.
Calls to FMOD_Studio_System_Update from multiple threads simultaneously should be fine, it’s just calls to FMOD_System_Create and FMOD_System_Release that are problematic.
A crash dump with memory would be ideal if you get any more crash reports in the future. Please let me know if you run into any other issues in the meantime.
Thank you for all the info and the investigation!
Okays, from your description it doesn’t seem like we’re doing anything bad then (we only init FMOD once of course). I’d sweep this under cosmic rays flippin’ bits for now - I’ll upgrade our FMOD version meanwhile, and report back if we catch it again.
Thanks again for your help, and have a great day!
1 Like
