# How does fmod.dll use SetUnhandledExceptionFilter()

**URL:** <https://qa.fmod.com/t/how-does-fmod-dll-use-setunhandledexceptionfilter/12699>\
**Category:** FMOD Engine\
**Created:** [September 16, 2016, 11:47am UTC](https://qa.fmod.com/t/how-does-fmod-dll-use-setunhandledexceptionfilter/12699 "2016-09-16T11:47:46Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![aweissflog](https://avatars.discourse-cdn.com/v4/letter/a/57b2e6/32.png) [@aweissflog](https://qa.fmod.com/u/aweissflog)\
**Post date:** [September 16, 2016, 11:47am UTC](https://qa.fmod.com/t/how-does-fmod-dll-use-setunhandledexceptionfilter/12699/1 "2016-09-16T11:47:46Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nick1](https://avatars.discourse-cdn.com/v4/letter/n/47e85d/32.png) [@nick1](https://qa.fmod.com/u/nick1)\
**Post date:** [September 19, 2016, 12:26am UTC](https://qa.fmod.com/t/how-does-fmod-dll-use-setunhandledexceptionfilter/12699/2 "2016-09-19T00:26:49Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![aweissflog](https://avatars.discourse-cdn.com/v4/letter/a/57b2e6/32.png) [@aweissflog](https://qa.fmod.com/u/aweissflog)\
**Post date:** [September 19, 2016, 7:16am UTC](https://qa.fmod.com/t/how-does-fmod-dll-use-setunhandledexceptionfilter/12699/3 "2016-09-19T07:16:14Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nick1](https://avatars.discourse-cdn.com/v4/letter/n/47e85d/32.png) [@nick1](https://qa.fmod.com/u/nick1)\
**Post date:** [September 20, 2016, 12:15am UTC](https://qa.fmod.com/t/how-does-fmod-dll-use-setunhandledexceptionfilter/12699/4 "2016-09-20T00:15:00Z")

</div>

> [@](#):
>
> 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

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.