FMOD Project Stuck at 99% Loading

Hello,

This morning, when I came into the office and launched FMOD, my project gets stuck at 99% while loading.

I have tried a wide range of troubleshooting steps to open the project (including disabling antivirus software, among many others), but none of them worked. The only method that allowed the project to open was deleting the following folder:

Metadata/EncodingSettings

However, even when the project opens this way, several serious issues occur:

  • After running Repair, all Platform settings are lost
  • Audio files do not play at all
  • When I try to Add Platform, FMOD becomes unresponsive, forcing me to terminate the program

Could you please help us identify the cause of this issue or suggest a way to recover the project without losing recent work?

Thank you very much for your help.

Best regards,


#update2

I’d like to update the situation. At first, we thought the issue was specific to our project files, but that doesn’t seem to be the case.

Even FMOD sample projects and any other projects freeze during loading. The program becomes unresponsive at around 90%–99% while loading, and eventually stays in a frozen state.

This happens consistently across all projects, not just our own.


#update3

I deleted all files under AppData and performed a clean reinstall of FMOD Studio, but the program itself will not launch properly. The process appears in the task manager, but no window or UI is displayed.

Interestingly, if I delete the EncodingSetting folder inside the example project, FMOD Studio finally launches. However, when I create a new project and then save and load it, the program gets stuck at 98% again.

In other words, regardless of the project or the FMOD Studio version, the program only launches successfully if the EncodingSetting folder is deleted. Otherwise, it either fails to show any window or gets stuck during loading.

This makes me think there is something wrong specifically on my PC related to encoding settings or the environment itself.
Could someone please help me understand what might be happening on my system and how to fix this?

I finally found the cause.
The culprit was the gamepad.

When I disconnected the gamepad’s USB and ran the program, FMOD launched normally.
It’s a bit absurd, but I’m curious why this happened and why only FMOD failed to run because of it.

Anyway, I’m just glad it’s solved.

Hi,

Thank you for the update and for sharing your solution here!

I have not been able to reproduce this on my end so far. Could you please share some more information about the controller so we can investigate further? Specifically:

  • The gamepad model
  • Your Windows version
  • The exact FMOD Studio version you tested

Also, if possible, could you please capture a dump file while FMOD Studio is hanging?

You can do this from Windows Task Manager:

  1. Launch FMOD Studio with the gamepad connected and wait until it hangs.

  2. Open Task Manager.

  3. Find the FMOD Studio process.

  4. Right-click it and choose “Create memory dump file”.

  5. Windows should show the location of the generated .DMP file.

  6. Upload the generated dump file to your Profile.

This should help us see where FMOD Studio is getting stuck during startup.

Below is an analysis of the root causes of this issue, compiled by AI. Would this be helpful?


Comment

I’d like to share a reproducible launch issue I encountered, which turned out to be related to a USB gamepad rather than graphics or storage.

Symptoms

  • FMOD Studio process starts, but no UI window appears.
  • CPU usage stays near zero.
  • FMOD Studio log file is not written at all (0 bytes).
  • Unplugging a my wireless gamepad immediately allows FMOD Studio to launch normally.

Hardware context

  • Wireless gamepad with a dedicated USB receiver.
  • The gamepad battery was nearly empty, so temporarily connected via USB cable (for charging / wired use).
  • The USB receiver was still connected at the same time.

Observed behavior When the gamepad was connected via USB in a low-battery state (while its wireless receiver was also present), FMOD Studio consistently failed to launch.
As soon as the gamepad was unplugged, FMOD Studio launched instantly without restarting the application or the OS.

Technical interpretation It appears FMOD Studio performs input device (HID / Raw Input) enumeration synchronously during early startup, before UI creation and before the logging system is fully initialized.

In this specific hardware state, Windows seems to stall or block during HID enumeration:

  • The same controller is exposed both as a USB HID device and via its wireless receiver.
  • Due to low battery, the device intermittently fails to respond correctly to descriptor or interface queries.
  • This causes the input enumeration call to block without timing out.

Because this happens before FMOD’s logging system becomes active, no log output is written at all (0-byte log file), and the application appears to hang silently.

Why this happens only in FMOD Studio Most applications either:

  • Enumerate input devices asynchronously, or
  • Perform input initialization after the main UI is already visible, or
  • Use timeouts when enumerating HID devices.

FMOD Studio appears to enumerate input devices synchronously and without a timeout before creating the main window.
As a result, it is more vulnerable to a single unresponsive HID device during startup, leading to a “process running but no UI” state with no logs.

Workaround

  • Avoid connecting the same wireless controller via USB while its wireless receiver is also connected.
  • Disconnect problematic HID devices when FMOD Studio fails to launch.
  • After removing the device, FMOD Studio launches normally.

I hope this information helps identify a potential edge case in the startup input device enumeration path.

My gamepad model is EasySMX X05. This issue does not appear to be caused by a specific gamepad. Rather, it seems to occur when a gamepad with a wireless receiver is connected via a wired connection at the same time. This issue did not occur when the gamepad was used exclusively in either wireless or wired mode.

I uploaded the requested memory dump file to my profile.

Thank you for the detailed information and for providing the dump file.

This helped us identify the issue, and our development team has started working on it. For now, please continue using your workaround.

I will update this thread when there is any further progress.

Thanks again for bringing this to our attention.