Now I've created a small MFC dialog with Play/Stop buttons with the call as shown above and it works fine on both XP and Windows 7. But for some reason because its running as a process it doesn't produce the sound.
I've tried loading the WAV file as a resource and using that but it just caused the process to continuing fall over.
Yes its started OK and running as a process its started by a service it would take a lot to change it to run as a exe. I did create a mfc app to just play/stop the wave file and it worked fine, I used the same play sound call with no problems
Well, an EXE is an EXE. I really can't imagine what you need to change to make the PlaySound() function call. But anyway, are you trying to produce sound from a Windows service? It might be problematic. I don't remember right now if that is allowed or not nowadays. The Session 0 thingy may be in the way.
Have you searched the web to see if there are reports on PlaySound() not working for services or for executables started from services?
EDIT: Wait, I thought the call to PlaySound() was in a different executable. If it is in a different executable, the service can continue to work with the other executable's main thread stuck. No need for a new thread.
Ok, it just hit me: Are you letting the process' thread die? Since it is a helper process with the only purpose of playing the sound and since you are playing it asynchronously, doesn't that mean that your executable dies shortly after the PlaySound() call? I rarely work with sound so I cannot be sure, but right now I am thinking that letting the executable die after PlaySound() also kills the sound.
This may not be happening in your MFC test app because it probably had a message loop? In any case I still support the synchronous playback test.