views:

500

answers:

5

The following code is causing an intermittent crash on a Vista machine.

using (SoundPlayer myPlayer = new SoundPlayer(Properties.Resources.BEEPPURE))
     myPlayer.Play();

I highly suspect it is this code because the prgram crashes mid-beep or just before the beep is played every time. I have top-level traps for all ThreadExceptions, UnhandledExceptions in my app domain, and a try-catch around Application.Run, none of which trap this crash.

Any ideas?


EDIT:

The Event Viewer has the following information: Faulting application [xyz].exe, version 4.0.0.0, time stamp 0x48ce5a74, faulting module msvcrt.dll, version 7.0.6001.18000, time stamp 0x4791a727, exception code 0xc0000005, fault offset 0x00009b30, process id 0x%9, application start time 0x%10.

Interestingly, the HRESULT 0xc0000005 has the message: "Reading or writing to an inaccessible memory location." (STATUS_ACCESS_VIOLATION)

+1  A: 

You can use WinDBG and trap all first-chance exceptions. I'm sure you'll see something interesting. If so, you can use SOS to clean up the stack and post it here to help us along.

Or you can use Visual Studio by enabling the trap of all exceptions. Go to "Debug" and then "Exceptions" and make sure you trap everything. Do this along with switching the debugger to mixed-mode (managed and unmanaged).

Once you have the stack trace, we can determine the answer.

A process doesn't exit on Windows without an exception. It's in there. Also, you might want to check the machine's Event Log to see if anything has shown up.

Frank Krueger
+1  A: 

The event viewer shows HRESULT 0xc0000005 "Reading or writing to an inaccessible memory location." (STATUS_ACCESS_VIOLATION)

See my edit above for more details; reproing this takes a while so I can't get a fresh crash dump for WinDBG for a little while.

Nick
A: 

The solution is to use Microsoft.VisualBasic.Devices, which does not suffer from this bug. Since it's Vista only, and the Event Viewer even managed to fail midway through logging the crash (process id 0x**%9** should have a hex value there instead), I point the blame at the new sound code in Vista.

BTW, connecting the VS debugger to the crashing process remotely managed to first hang Visual Studio, then cause a BSOD on my machine while killing the non-responsive devenv.exe. Wonderful!

Nick
A: 

Pure speculation here, but the problem may be the using statement. Your code is like this (I think):

using (SoundPlayer myPlayer = new SoundPlayer(BEEPPURE))
{    
    myPlayer.Play();
}

The using block will call Dispose() on myPlayer, sometimes before it is done playing the sound (but rarely, because the sound is so short - with a longer sound, I'll bet you can reproduce the error every time). The error would be the result of the Windows API (which SoundPlayer wraps) trying to play a buffer which has already been disposed by .NET.

I think if you do this:

SoundPlayer myPlayer = new SoundPlayer(BEEPPURE);
myPlayer.Play();

or even

(new SoundPlayer(BEEPPURE)).Play();

you will not see the error any more.

MusiGenesis
I guess not. I can't reproduce the error, even with a using block.
MusiGenesis
+1  A: 

Actually, the above code (that is, new SoundPlayer(BEEPPURE)).Play(); was crashing for me.

This article explains why, and provides an alternative to SoundPlayer that works flawlessly:

http://www.codeproject.com/KB/audio-video/soundplayerbug.aspx?msg=2862832#xx2862832xx