在研究这个问题的时候，我在网上发现了多个关于以下场景的提及，总是在编程论坛上没有答案的问题。 我希望在这里发表，至less可以logging我的发现。
首先，症状：运行使用waveOutWrite（）输出PCMaudio的相当标准的代码时，有时在debugging器下运行时会出现这种情况：
ntdll.dll!_DbgBreakPoint@0() ntdll.dll!_RtlpBreakPointHeap@4() + 0x28 bytes ntdll.dll!_RtlpValidateHeapEntry@12() + 0x113 bytes ntdll.dll!_RtlDebugGetUserInfoHeap@20() + 0x96 bytes ntdll.dll!_RtlGetUserInfoHeap@20() + 0x32743 bytes kernel32.dll!_GlobalHandle@4() + 0x3a bytes wdmaud.drv!_waveCompleteHeader@4() + 0x40 bytes wdmaud.drv!_waveThread@4() + 0x9c bytes kernel32.dll!_BaseThreadStart@8() + 0x37 bytes 虽然明显的嫌疑人会在代码中的其他地方堆积腐败，但我发现事实并非如此。 此外，我能够使用下面的代码重现此问题（这是基于对话框的MFC应用程序的一部分:)
void CwaveoutDlg::OnBnClickedButton1() { WAVEFORMATEX wfx; wfx.nSamplesPerSec = 44100; /* sample rate */ wfx.wBitsPerSample = 16; /* sample size */ wfx.nChannels = 2; wfx.cbSize = 0; /* size of _extra_ info */ wfx.wFormatTag = WAVE_FORMAT_PCM; wfx.nBlockAlign = (wfx.wBitsPerSample >> 3) * wfx.nChannels; wfx.nAvgBytesPerSec = wfx.nBlockAlign * wfx.nSamplesPerSec; waveOutOpen(&hWaveOut, WAVE_MAPPER, &wfx, (DWORD_PTR)m_hWnd, 0, CALLBACK_WINDOW ); ZeroMemory(&header, sizeof(header)); header.dwBufferLength = 4608; header.lpData = (LPSTR)GlobalLock(GlobalAlloc(GMEM_MOVEABLE | GMEM_SHARE | GMEM_ZEROINIT, 4608)); waveOutPrepareHeader(hWaveOut, &header, sizeof(header)); waveOutWrite(hWaveOut, &header, sizeof(header)); } afx_msg LRESULT CwaveoutDlg::OnWOMDone(WPARAM wParam, LPARAM lParam) { HWAVEOUT dev = (HWAVEOUT)wParam; WAVEHDR *hdr = (WAVEHDR*)lParam; waveOutUnprepareHeader(dev, hdr, sizeof(WAVEHDR)); GlobalFree(GlobalHandle(hdr->lpData)); ZeroMemory(hdr, sizeof(*hdr)); hdr->dwBufferLength = 4608; hdr->lpData = (LPSTR)GlobalLock(GlobalAlloc(GMEM_MOVEABLE | GMEM_SHARE | GMEM_ZEROINIT, 4608)); waveOutPrepareHeader(hWaveOut, &header, sizeof(WAVEHDR)); waveOutWrite(hWaveOut, hdr, sizeof(WAVEHDR)); return 0; }
在任何人评论之前，是的 – 示例代码播放未初始化的内存。 不要试图将您的扬声器翻过来。
一些debugging显示了以下信息：waveOutPrepareHeader（）使用一个指针来填充header.reserved，该指针看上去是一个包含至less两个指针的结构，作为其前两个成员。 第一个指针设置为NULL。 在调用waveOutWrite（）之后，该指针被设置为在全局堆上分配的指针。 在伪代码中，这看起来像这样：
struct Undocumented { void *p1, *p2; } /* This might have more members */ MMRESULT waveOutPrepareHeader( handle, LPWAVEHDR hdr, ...) { hdr->reserved = (Undocumented*)calloc(sizeof(Undocumented)); /* Do more stuff... */ } MMRESULT waveOutWrite( handle, LPWAVEHDR hdr, ...) { /* The following assignment fails rarely, causing the problem: */ hdr->reserved->p1 = malloc( /* chunk of private data */ ); /* Probably more code to initiate playback */ }
通常情况下，通过wdmaud.dll内部函数waveCompleteHeader（）将头返回给应用程序。 waveCompleteHeader（）通过调用GlobalHandle（）/ GlobalUnlock（）和朋友试图释放由waveOutWrite（）分配的指针。 有时GlobalHandle（）炸弹，如上所示。
现在，GlobalHandle（）炸弹的原因不是由于堆腐败造成的，因为我首先怀疑这是因为waveOutWrite（）返回时没有将内部结构中的第一个指针设置为有效的指针。 我怀疑它返回前释放指针指向的内存，但我还没有反汇编它。
这似乎只发生在波形回放系统在缓冲区低时，这就是为什么我使用单个标题来重现这一点。
在这一点上，我有一个很好的例子，这是我的应用程序中的一个错误 – 毕竟，我的应用程序甚至没有运行。 有没有人见过这个？
我在Windows XP SP2上看到了这一点。 声卡来自SigmaTel，驱动程序版本是5.10.0.4995。
笔记：
为了避免将来的混淆，我想指出一个问题，那就是使用malloc（）/ free（）来pipe理正在播放的缓冲区是一个错误。 你会注意到我改变了上面的代码来反映这个build议，以防止更多的人犯同样的错误 – 这没有什么不同。 由waveCompleteHeader（）释放的缓冲区不是包含PCM数据的缓冲区，释放PCM缓冲区的责任在于应用程序，并且没有要求以任何特定方式分配。
此外，我确保我使用的任何waveOut API调用都不会失败。
我目前假设这是Windows中的错误或audio驱动程序中的错误。 反对意见总是受欢迎的。
您并不孤单与此问题： http : //connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=100589
现在，GlobalHandle（）炸弹的原因不是由于堆腐败造成的，因为我首先怀疑这是因为waveOutWrite（）返回时没有将内部结构中的第一个指针设置为有效的指针。 我怀疑它返回前释放指针指向的内存，但我还没有反汇编它。
我可以用你的代码在我的系统上重现这一点。 我看到类似于约翰内斯报道的东西。 在对WaveOutWrite的调用之后，hdr-> reserved通常会保存一个指向已分配内存的指针（除了别的以外，它似乎包含了波形输出设备名称）。
但偶尔从WaveOutWrite（）返回后， hdr->reserved指向的字节被设置为0.这通常是该指针的最低有效字节。 hdr->reserved中剩余的字节是可以的，并且它通常指向的内存块仍然被分配并且不被破坏。
它可能正在被另一个线程所破坏 – 我可以在调用WaveOutWrite（）之后立即捕获有条件断点的变化。 系统调试断点发生在另一个线程，而不是消息处理程序。
但是，如果我使用回调函数而不是Windows消息泵，则不会导致系统调试断点发生。 （在WaveOutOpen（）中fdwOpen = CALLBACK_FUNCTION ）当我这样做时，我的OnWOMDone处理程序被另一个线程调用 – 可能是另一个负责破坏的线程。
所以我认为有一个错误，无论是在Windows或驱动程序，但我认为你可以通过处理WOM_DONE回调函数，而不是Windows消息泵。
我看到了同样的问题，并自己做了一些分析：
waveOutWrite（）分配（即GlobalAlloc）指向一个354字节的堆区域的指针，并正确地将其存储在header.reserved指向的数据区域中。
但是，当这个堆区被再次释放（在waveCompleteHeader（）中，根据你的分析;我没有wdmaud.drv的符号），指针的最低有效字节被设置为零，因此无效指针（而堆没有被破坏）。 换句话说，发生的事情是这样的：
所以我不同意你的陈述：waveOutWrite（）首先存储一个有效的指针; 该指针只会在另一个线程中被破坏。 也许这是相同的线程（mxdmessage），后来试图释放这个堆区，但我还没有找到零字节存储的地步。
这不经常发生，并且相同的堆区（相同的地址）已经被成功地分配和释放。 我相当确信这是系统代码中的某个错误。
不确定这个问题，但是你有没有考虑过使用更高级别的跨平台音频库？ Windows音频编程有很多怪癖，这些库可以为您节省很多麻烦。
例子包括PortAudio ， RtAudio和SDL 。
我要做的第一件事就是检查waveOutX函数的返回值。 如果它们中的任何一个都失败了 – 在你描述的情况下这不是不合理的 – 而且你继续，不管怎么说，事情开始出错是不足为奇的。 我猜测waveOutWrite会在某个时候返回MMSYSERR_NOMEM。
使用应用程序验证器来弄清楚发生了什么，如果你做了一些可疑的事情，它会很早就捕捉到它。
Wine查看Wine的源代码可能会有所帮助，尽管Wine有可能修复了Wine的任何错误，Wine也可能有其他的缺陷。 相关的文件是dlls / winmm / winmm.c，dlls / winmm / lolvldrv.c，还有其他的。 祝你好运！
那么你不允许从回调中调用winmm函数呢？ MSDN没有提到有关窗口消息的限制，但窗口消息的使用与回调函数类似。 可能在内部它是作为驱动程序的回调函数实现的，并且回调函数是SendMessage。 在内部，waveout必须维护使用waveOutWrite写入的头的链表; 所以我猜想：
hdr->reserved = (Undocumented*)calloc(sizeof(Undocumented));
设置链表的上一个/下一个指针或类似的东西。 如果你写更多的缓冲区，那么如果你检查指针，如果它们中的任何一个指向另一个，那么我的猜测很可能是正确的。
网络上的多个来源指出，您不需要反复准备/准备相同的标题。 如果您在原始示例中注释掉Prepare / unprepare标题，那么它看起来工作正常，没有任何问题。
我通过查询声音播放和延迟来解决问题：
WAVEHDR header = { buffer, sizeof(buffer), 0, 0, 0, 0, 0, 0 }; waveOutPrepareHeader(hWaveOut, &header, sizeof(WAVEHDR)); waveOutWrite(hWaveOut, &header, sizeof(WAVEHDR)); /* * wait a while for the block to play then start trying * to unprepare the header. this will fail until the block has * played. */ while (waveOutUnprepareHeader(hWaveOut,&header,sizeof(WAVEHDR)) == WAVERR_STILLPLAYING) Sleep(100); waveOutClose(hWaveOut);
使用waveOut界面在Windows中播放音频