Model : ASUS TUF FX505GM-BQ251
OS : Windows 11 Pro (10.0.22621)
Audio dirver : Realtek(R) Audio
Record driver : Abnormal (blank)
FMOD Core : 2.02.09
A Crash when calling fmod recordGetDireverInfo.
In this case, getRecordNumDrivers returns error FMOD_ERR_OUTPUT_INIT.
I ignored it, but a crash occurred in fmod System::update.
fmod.dll!FMOD_strcpy_safe(char * dst, const char * src, int destBytes) line 120 C++
fmod.dll!FMOD::OutputWASAPI::recordGetDriverInfo(int) line 717 C++
fmod.dll!FMOD::recordGetDriverInfoCallback(FMOD_OUTPUT_STATE * output, int id, char * name, int nameLen, FMOD_GUID * guid, int * systemRate, FMOD_SPEAKERMODE * speakerMode, int * speakerModeChannels) line 990 C++
fmod.dll!FMOD::SystemI::updateRecordCache() line 4961 C++
fmod.dll!FMOD::SystemI::updateInternal(bool checkdriverlist) line 168 C++
fmod.dll!FMOD::System::update() line 578 C++
The record dirver name is empty(blank), when checking in Windows sound settings.
It look like in an abnormal environment.
When resetting the record device, it is changed to a state without a record device(no record device).
However, unless disable or renew an abnomal device, it will remain in that state permanently.
For some unknown reason, Windows did not completely remove the record device, ramains dummy information.
This problem occurs is the user’s PC, so there is nothing we can do about it.
Is it possible to disable update record device? (recordGetDireverInfo)
After looking into the issue, it does seem to be related to the abnormal record driver’s name, though I’ve been unable to reproduce the issue exactly. Would it be possible to provide me with a dxdiag and a log of the crash from the user so that I can look into the exact data from device info that is causing the crash? If you can do so, I may be able to diagnose the problem in greater detail and flag it internally for a fix.
Obviously having the user fix the abnormal record driver on their end would probably be best, but a workaround would be to set an empty callback of type FMOD_SYSTEM_CALLBACK_RECORDLISTCHANGED with the following line system->setCallback(0, FMOD_SYSTEM_CALLBACK_RECORDLISTCHANGED);. Setting a custom callback like this will stop FMOD from calling the problematic code from System::update - however, in doing so it also stops FMOD from automatically updating the driver list.
Unfortunately, no additional logs were obtained.
When contacting the user with the problem, it did not occur after forced initialization of the record driver list.
It seems to happen very infrequently, with only two cases reported in about a year.
I think it seems to happen, getRecordNumDrivers returns error FMOD_ERR_OUTPUT_INIT.
Only this case, I decided to set an empty callback of type FMOD_SYSTEM_CALLBACK_RECORDLISTCHANGED