How does fmod.dll use SetUnhandledExceptionFilter()

FMOD Engine
1

Hi,

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)?

Thanks!
-Floh

2

We don’t call SetUnhandledExceptionFilter(). Every windows DLL end up with a dependency on that function.

When the callstack doesn’t make sense it’s probably due to lack of symbols.

3

The strange thing is that there are multiple identical addresses on followup-slots in the callstack, most of these point into the FMOD_Studio_VCA_SetFaderLevel() function.

Are there any known problems with Visual Studio 2015? Client-side crashes have gone up since we compile our client with VS2015 (before we were still on VS2010). We’re on FMOD 1.8.2

4

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.