I’m currently investigating client-side ACCESS_VIOLATION_EXCEPTION crashes that seem to origin in the fmod.dll but cannot be reproduced by us.
I noticed that fmod.dll seems to install a Win32 exception handler (at least I’m seeing SetUnhandledExceptionFilter() as dependency when doing a dumpbin /IMPORTS fmod.dll)
Since we’re also installing an exception handler, and the callstack information we are getting from there don’t make much sense I am wondering whether our own exception handler and the FMOD exception handler somehow collide.
So my question is: what exactly is FMOD doing in its own exception handler, and which of the 2 possible return values does it return (EXCEPTION_CONTINUE_SEARCH or EXCEPTION_EXECUTE_HANDLER)?
When Microsoft’s debugging tools can’t find a PDB with the private symbols, it simply uses the nearest (in terms of memory address) public symbol from the DLL. So you end up with a callstack containing random public API functions.
We compile and run our automated tests with VS2015 for UWP, but we have no test coverage for VS2015 with win32 builds.