Ever since I added sound to my game, it occasionally crashes with an access violation when I quit it, deep inside some native code. This is most common when quitting with Alt-F4, but sometimes happens when doing a "clean" quit as well (back out of game/menu using the controller).

The stack trace of the crash is:

at Microsoft.Xna.Framework.Audio.UnsafeNativeMethods.Cue.GetStatus(IntPtr pCue)
at Microsoft.Xna.Framework.Audio.Cue.get_IsPlaying()
at Microsoft.Xna.Framework.Audio.Cue.Finalize()


I have finalizers in my game that makes sure that all Cues are properly quit, but the collection and execution order of finalizers is not defined, so that's not a robust mechanism for the termination case. However, I think that the whole point of a managed API should be that it couldn't crash in native code, so I believe there's a bug somewhere in the XACT implementation for XNA.

Is this known? Should I file it on Connect? Is there some way I can debug this on my side?

We have one known issue with cue finalizers, which I would guess is the same thing you are hitting here, but if you have a small enough repro case to post on Connect, that would certainly be useful to verify that this really is the same issue.

Thanks, Shawn! Will there be a patch, or do we have to wait for 3.0?
No, my repro case is rather large and complex :-(

I fear this will be a 3.0 fix.

I fear this will be a 3.0 fix.

That's unfortunate. (Perhaps if I found a way to turn this AV into a remotely exploitable security hole, it would get fixed sooner ;-)
Is there a user-level work-around?

jwatte:

That's unfortunate. (Perhaps if I found a way to turn this AV into a remotely exploitable security hole, it would get fixed sooner ;-)

<grin>

jwatte:

Is there a user-level work-around?

I think (but am not absolutely confident) the root problem is a race condition to do with cues getting finalized while they are still playing. If you manually hold on to your cue references and only let these be collected after you are sure they have stopped, I think that will avoid the issue.

I haven't actually implemented the fix for this yet, though, so I might be misunderstanding the details of what exactly causes it. It boils down to something that ought to be locked, but is not, but I'm not 100% solid on how to workaround that.

I get the same error when the game is running.

The Windows version of my game works fine. The exception only occurs in the XBox version.

My work-around, so far, is to never unload a wavebank or sound bank. I also hold on to cues in an internal list as soon as I've played them, and check that list for IsStopped, and don't release the cue from the list until it's actually stopped. That seems to fix most of the problems, but it's annoying to have to check that list each time through Game.Update().

Thank you for your advice.

This seems like a major problem... Are we the only ones with these exceptions?

jwatte:

My work-around, so far, is to never unload a wavebank or sound bank. I also hold on to cues in an internal list as soon as I've played them, and check that list for IsStopped, and don't release the cue from the list until it's actually stopped. That seems to fix most of the problems, but it's annoying to have to check that list each time through Game.Update().

 

Hi, Jon

I was playing around with your suggestions but didn't succeed...

Can you give me some code examples of your work-around and some more detailed information of your solution?

 

Thank you in adv! Zilla

I did some human garbage collection in XACT because I realised that my code "lost" the sound banks when I had more than one or two open:

I deleted all the unused wave files, banks and cues. Then I reorganised my XACT project and the code and threw everything into two sound and two wave banks (background music and sound effects).

It seems that this solved my problem because the game doesn't crash anymore :-)