http://bugs.winehq.org/show_bug.cgi?id=28413
--- Comment #13 from Andrew Eikum aeikum@codeweavers.com 2011-10-28 10:42:05 CDT --- (In reply to comment #12)
so any WinMM calls within the callbacks would fail
It's not external calls that fail, it's winmm internally which got corrupt, as one call had already progressed past the "fetch object if handle ok" check in winmm then got preempted, then another thread closed the device. => crash when the first thread resumes.
I'll have to carefully review the current winmm code, but I can't remember seeing protections like InterlockedIncrement around winmm calls which I see as a means to verify that no other thread is currently using a given handle, so I have some doubts it's safe now. Is there any other means?
Well, every time a device object is accessed, the thread doing the accessing holds the device's mutex. And every time a mutex is obtained, the device's validity is checked, usually by ValidateAndLock(), but also sometimes by things like "device->device," which will be non-NULL iff the device is open. I guess these checks could be made consistent (always check device->open, or eliminate device->open and check something else like device->device).
I would welcome your own analysis, though.
clicked like crazy
You want to configure windows/win.ini, see bug #21277 comment #3 to use PlaySound via my MCI shell: sound default sound systemasterisk notify sound systemexclamation notify [copy&paste a dozen of these lines from an editor to a wine console]
Did this test a few dozen times with the patch applied and saw no failures.