呼叫iDirectSoundBuffer8 :: play时,指示崩溃是由于读取访问违规而导致的(lfqueueput,dsound.dll内部函数)
我正在研究游戏,并且在dsound.dll内偶尔观察崩溃。
这在创建iDirectSoundBuffer8音频缓冲区(在其上调用play方法)后立即发生。在这一点上,除了创建音频设备,设置合作级别,创建音频缓冲区并开始播放之外,我还没有写信给缓冲区或对声音系统做任何事情。
所有通过直接返回的值都表示成功,即使我明确查询诸如DSERR_BUFFERLOST之类的缓冲区,也没有指示错误的迹象。
这是CallStack:
I am working on a game, and am sporadically observing crashes inside of dsound.dll.
This happens right after creating a IDirectSoundBuffer8 audio buffer, when calling the Play method on it. At this point I haven't written to the buffer or done anything to the sound system besides creating the audio device, setting the cooperative level, creating the audio buffer and starting to play.
All values returned by DirectSound indicate success, and even when I explicitely query the buffer for things like DSERR_BUFFERLOST, no sign of error is indicated.
This is the callstack:
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
通过消除过程来搜寻此错误后,这似乎是一个Windows/驱动程序问题。 简而与此分配互动。
我能够产生以下repro,这会使其他所有执行崩溃(尽管我的应用程序中的崩溃率低至5%)。我能够在2个PC上复制它,而另一个尝试它也能够复制的人。不过,您必须在调试器中执行此代码,因为否则您将无法正常违反访问违规而区分崩溃:
我没有找到解决此问题的解决方案,并且由于没有真正的方法为了向微软报告这种错误实际上是固定的,我决定将其放在stackoverflow上,以便其他人希望不会像我那样浪费太多时间。接下来,我可能会尝试使用Wasapi。
After hunting this bug down by process of elimination, it seems to be a Windows/Driver issue. In short: DirectSound may crash your application if you reserve 10 TiB of address space. I'm using this address space for a debug allocator that helps hunting down use-after frees, and for some reason DirectSound seems to interact with this allocation.
I was able to produce the following repro, that crashes about every other execution (although I have also seen crash rates as low as 5% in my application). I was able to reproduced this on 2 PCs, and one other person who tried it was also able to reproduce. You have to execute this code in a debugger though, because otherwise you won't be able to distinguish a crash due to access violation from the execution finishing normally:
I have not found a solution to this issue, and since there is no real way to report such a bug to microsoft with any hopes of it actually getting fixed, I decided to put this on Stackoverflow so that other people hopefully don't waste as much time on it as I have. I will probably try using WASAPI instead next.