• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

XAudio2_.dll stops debugging

Dutch

Dutch

Messages
158
Country
us-northcarolina
Here's one that's driving me up the wall. One of my co-developers has the exact same problem on his PC which not the same as mine at all. So it's not related to my drivers or OS corruption or anything like that. It's not unique to my installation. The same problem occurs on different gauge projects that don't share any code at all, so it's not a problem in the project or my source code.

We use Visual Studio 2013 to debug our C++ gauges, and we use "connect to process" to connect to FSX. This worked just fine when I was using 32-bit Windows 7. So, I upgrade to 64 bit Seven. Now I can't debug the gauge. Here's what happens.

Anytime I set a breakpoint, when the breakpoint is hit an access violation 0xc00000005 is thrown from a module XAudio2_6.dll. Always the same instruction. On both our PCs on opposite ends of the country.

The options are to debug, abort, or continue. If I continue, the same access violation reappears endlessly. If I debug, it will place me in the assembly code where I can see the X86 instruction that's causing the access violation. (It's in XAudio2_7.dll, naturally.) If I abort, FSX crashes.

So I can't use any breakpoints. Debugging is pretty pointless without breakpoints. I don't care a whit about this XAudio2_6.dll problem itself. I just want it to stop bringing my debugging sessions to a crashing halt.

Outside of the debugger, FSX runs smoothly without apparent problems. Even with the debugger connected no access violation is reported until a breakpoint is hit.

Anyone seen this, and is there a solution?

Thanks
Dutch
 
When you google xaudio2, you get some forum threads that say it has trouble with DX 11. Since XAudio is not yours, you can't get a debug version of the code , that's why breakpoints don't work.

So maybe there is a conflict with DX11 64 bit.

See this thread, may or may not help. I have not tried it.

http://www.grimrock.net/forum/viewtopic.php?f=12&t=513&start=10

Perhaps downloading microsofts DX redist will help. - Again I have not tried it.
 
ronh said:
When you google xaudio2, you get some forum threads that say it has trouble with DX 11. Since XAudio is not yours, you can't get a debug version of the code , that's why breakpoints don't work.

So maybe there is a conflict with DX11 64 bit.

See this thread, may or may not help. I have not tried it.

http://www.grimrock.net/forum/viewtopic.php?f=12&t=513&start=10

Perhaps downloading microsofts DX redist will help. - Again I have not tried it.
Click to expand...

A good idea. I gave it a try just now. It did change the address where it crashes, but that's about it. Still an Access Violation in XAudio2_6.dll, same instruction.

I admit I'm baffled about how this all works, and why it runs without crashing until I attach the debugger, and why it only crashes (or reports the access violation) the instant it hits my breakpoint.

Another oddity: it only seems to crash in certain areas. When debugging the KLN90B, which has multiple modules that are linked together, I can set a breakpoint and it will work in any module except the main one, the one that implements the FSAPI loop. If I set one in that loop anywhere, I get the XAudio2_6.dll access violation trap. Is that because that module is considered to be in the FSX address space or ring, but the others are outside it?

It must catch the error (or something does) and continue during normal (no debugger attached) FSX operations. I guess because there's a debugger attached it feels compelled to report the error to it and bring down the house.

Puzzled.

Dutch
 
Thanks for your suggestions, I know this is frustrating and hard to track down. I will check out your link. But it's hard to believe we (FSCaptain) are the only developers that run into this.

Does no one else use the Visual Studio debugger and attach to gauge code running inside FSX? I do, all the time, not just for debugging but for development. (Edit-and-continue is a wonderful thing!) And if you do, do you not have this happen to you?

We don't do anything with XAudio. We don't use the DirectSound API at all. We use the old GaugeSound.dll for sound effects and the Windows MCI API for music and voice. I didn't even know XAudio existed until this happened. I presume FSX itself is using it and that's where it's getting involved

To recap the clue set:

- This appeared when I moved from 32 bit to 64 bit Windows 7. So it's related to 64 bit operation but not 32 bit.

- I thought moving from VS2008 to VS2013 would solve it. It did not. So it's not related to the VS platform.

- I updated all my drivers and even swapped out my sound card for a different one from a different manufacturer. Still breaks, same place. So it's not a driver problem, as many on the Internet suggested.

- I thought when I started working on the KLN90B code I at least wouldn't have this problem since it didn't use sound. No, same problem, same place. So it's not related to anything in the source code itself.

- It also happens with my colleague who has a completely different PC with a totally different sound system, processor, motherboard, video card -- nothing is the same. It's not hardware related.

But I did discover I could set a breakpoint in any module except the main DLL entry one that implements the FSAPI loop (with the switch statement that contains
case PANEL_SERVICE_PRE_DRAW: and the rest of the cases FSAPI provides to the gauge DLL.) But what does this fact mean?

With that set of clues, I should be able to figure this out.

My current working theory is that there's a problem or bug with FSX and 64-bit Xaudio2_6.dll. FSX traps it and goes on and the user never knows it. But when a debugger is attached, whammo. If that's true, there's little I can do to "fix" it, unless there's another redist of DX out there that corrects this.

So what I want to do is tell the dang debugger to just not break unless there's a problem in MY code. Other code: just catch it and move on. Please. Don't stop.

Right now I'm going to try and turn off all sound in FSX and see if that will get me past this. Interestingly, disabling all the sound systems on the PC (I tried that too) will cause FSX to crash during initialization.
 
Last edited:
Update: Nope, unchecking all sounds in FSX doesn't prevent XAudio2_6.dll from crashing at 0x6DB8CBEF with a 0xc00000005. For grins, here's the machine code it always crashes on:

Code: 
6DB8CBD6  mov         eax,dword ptr [ebp+8]
6DB8CBD9  cmp         dword ptr [eax+38h],0
6DB8CBDD  je          6DB8CC10
6DB8CBDF  mov         ecx,dword ptr [ebp+10h]
6DB8CBE2  push        ecx
6DB8CBE3  mov         edx,dword ptr [ebp+8]
6DB8CBE6  mov         eax,dword ptr [edx+38h]
6DB8CBE9  mov         ecx,dword ptr [ebp+8]
6DB8CBEC  mov         edx,dword ptr [ecx+38h]
6DB8CBEF  mov         eax,dword ptr [eax]  <-------------------------- Bam!
6DB8CBF1  push        edx
6DB8CBF2  mov         ecx,dword ptr [eax]
6DB8CBF4  call        ecx
6DB8CBF6  movss       xmm0,dword ptr ds:[6DB61314h]
6DB8CBFE  movss       dword ptr [ebp-4],xmm0
6DB8CC03  fld         qword ptr ds:[6DB61448h]
6DB8CC09  fld         dword ptr [ebp-4]
 
If your programs are residing in the "Program Files" folder (because you simply upgraded your OS)... that could be a potential source of the problem. In the 32-bit OS... "Program Files" is the default installation folder for applications. In the 64-bit OS... "Program Files" is the default installation folder for 64-bit applications and "Program Files (x86)" is the default installation folder for 32-bit applications.
 
Well, certainly FSX itself is out of Program Files (x86). It's in C:\FSXA. Visual Studio 2013 is wherever MS decided to put it when I installed it from the web. I hope they know the right place :)

There are no other programs involved. The gauge is a DLL running inside FSX.
 
You talk about 64-bit XAudio2_6.dll... but FSX is a 32-bit application and would not load a 64-bit DLL. I don't think it would even be possible. So... if indeed the DLL is a 64-bit DLL... then it's an application that is being mistaken as being 64-bit that's triggering the DLL load for DirectX audio which that DLL is the 'replacement' of.
 
I say the 64 bit XAudio2_6.dll because it is located in Windows/SysWOW64. I assume the things in there are 64 bit. It's right next to Windows/System32. There are actually quite a few XAudios in there, here's a screenshot:

upload_2015-1-26_0-46-20.png


I took a look in Windows/System32 and guess what? They are all in there too, and they appear identical to the ones in SysWOW64. Same names, dates, and sizes. So maybe it is 32 bit after all.

What this means I don't know but either it's normal, or MS has a huge bug, as i haven't been touched any of this stuff.

Bear in mind that FSX works just fine and plays sound without difficulty. So everything here is not screwed up or out of place.
 
The Goggle has a note about a few people having trouble with XAudio2. Does your gauge call a dll for sound that you don't control? Seems there is an API for XAudio that can be used for C++ programming.

Anyway there is a thread re all this, but unless you have access to the sound dll/exe that implements xaudio, you may be out of luck. Perhaps it's FSX that loads it?

http://stackoverflow.com/questions/16049677/xaudio2-access-violation-exception-when-unloaded

BTW i have windows 8 and have XAudio2_8.dll, but this is not my FSX system. Anyone know if FSX loads XAudio?
 
We do use GaugeSound.dll which is a complete black box to me. I don't know how it does what it does. I wouldn't be surprised at all if it doesn't invoke XAudio. I can easily disable the loading of GaugeSound as a test.

I also have a complete virgin, untouched FSX-SE install that I use for compatibility testing. I'll see what the original audio-less KLN90B does on that. If XAudio is involved at all then, FSX is loading it.
 
XAudio is used by FSX... GaugeSound was created long before XAudio existed and thus I suspect it uses DirectSound.
 
I think there are a number of Gaugesound.dlls out there. What is the date and size? 2003 and 40K (EasyGauge??) and then the one by Mr. Dawson 2013 and 97K. Maybe you can sub in Dougs version - with source.

edit:

One last item: there is a blog about VS2012 and 2013 and the differences that may affect DirectSound and other SDK's and platform toolsets

http://blogs.msdn.com/b/chuckw/archive/2012/11/26/visual-studio-2012-update-1.aspx
 
Last edited:
Ed is correct, the original gaugesound.dll uses DirectSound, as does the replacement I coded.
 
I think we're using the original.

I'm excited to hear about a replacement :) By Doug...extremely excellent.

And I am glad to hear WarpD confirm that it's FSX that's using XAudio. This is as I suspected. I can't find anything else that does that's involved in this.
 
Sorry to dig this up, but I had FSX crash on me three times in the last few hours and each time, XAudio2_7.dll was the module that dragged things down south.

Sample log:
Code: 
Faulting application name: fsx.exe, version: 10.0.62615.0, time stamp: 0x559f9a9a
Faulting module name: XAudio2_7.dll_unloaded, version: 9.29.1962.0, time stamp: 0x4c0641e5
Exception code: 0xc0000005
Fault offset: 0x0003a5e0
Faulting process id: 0x1ee4
Faulting application start time: 0x01d2bbaaa655e9a3
Faulting application path: E:\SteamLibrary\steamapps\common\FSX\fsx.exe
Faulting module path: XAudio2_7.dll
Report Id: eaf425e4-c457-4cce-9e2e-fc41f832d42c
Faulting package full name:
Faulting package-relative application ID:


All I did in the sim was reloading the aircraft a few times and dragging it to another airport while airborne in slew mode.

I'm not using any fancy experimental sound-related modules, just Doug's XML sound gauge (v5.2.0) and another third party sound module (managing a trim sound).

One thing I've tried was deactivating the "Touch Keyboard and Handwriting Panel Service" in Windows 10 as this allegedly helps in some cases*. After another test, I still got the crash.

Since then, I've reinstalled the DirectX 2010 redistributable runtimes, though as far as I could see, it didn't add any missing .dlls. I've updating Doug's gauge to v5.2.3 and removed the other sound module to have Doug's gauge manage the trim sound.


All in all, it looks like this is a bug in DirectX. Unlike Dutch, I'm using Windows 10 x64.


* https://steamcommunity.com/app/311560/discussions/0/528398719804196382/#c154642901279773832
https://answers.microsoft.com/en-us...-desktop/problem-with-xaudio27dll-win-10-64x/
http://steamcommunity.com/app/220240/discussions/0/496881136920428261/
 
Last edited:
You must log in or register to reply here.
Back
Top