首先，我是一位经验丰富的图形程序员，但众所周知，每个人都会犯错误。不幸的是，代码库有点太大了，无法在这里开始抛出合理的片段，并且在一个孤立的CPP /代码库中重新创建整个情况的命令太高了 - 对不起，我没有时间。我会尽力解释。
B.t.w，如果有人想知道我是如何处理这个或那个，我当然会提供具体的代码片段。
与D3DPOOL_DEFAULT池中的所有资源一样，当设备上下文被带走时，您迟早将不得不重置资源。我已经建立了一个机制来处理已经工作多年的所有相关资源;但是，尽管我已经检查过，断言并怀疑任何假设，因为这个错误已经曝光。
发生的情况如下：我有一个相当大的动态顶点缓冲区，精确大小为18874368字节。在生成动态几何（isosurface-related，f.y.i）之前，每个帧都锁定（并完全使用D3DLOCK_DISCARD标志丢弃）此缓冲区。这很好，直到我开始重置。它可能需要1次，可能需要2次，或者可能需要5次重置才能引发一个错误，导致访问冲突 对更新资源上的Lock（）操作返回的指针<或em普通崩溃 - 关于一个有点类似的地址，但没有它在第一种情况下加入它的偏移，因为在那种情况下我们在写中途的某个地方 - 在D3D9 dll Lock（）调用之外。
我在其他硬件上测试了这个，将我的GMA X3100驱动程序（使用带有BootCamp的MacBook）升级到最新的驱动程序，但我无法在任何其他机器上重现它，我对于什么是错误感到茫然这里。我试图用类似的缓冲区重现类似的情况（我有一个相同类型的大型便笺簿，我填充了四边形）并且超过一定数量的字节，它开始表现得同样。
我不是在这里要求解决方案，但我很感兴趣，如果这里有其他开发人员与同一个敌人进行过斗争，或者有些人可能会指出一些有见地的方向，也许会问一些可能会流下的问题点亮我可能会或不会忽略的东西。
谢谢，任何更正都非常受欢迎。
p.s - 我的一位朋友提出了一个有效的观点，即它对于板载视频RAM是一个巨大的缓冲区，并且由于它的动态特性，它至少在内部被双重或三重缓冲。另一方面，调试输出（D3D9调试DLL +最大警告输出）保持静默。
ps 2 - 如果它在更多的机器上进行测试并且仍然可以工作 - 这可能是一个环境问题：巨大的动态，内部双/三重缓冲缓冲区，而不是很多内存和驱动程序不要抱怨他们应该......
ps 3 - 刚刚被告知（应该已经知道）锁定和解锁执行18MB的完整副本 - 这也不是太聪明，但仍然是:)（我确实使用了这个更精简的策略来渲染渲染器的通用动态VB / IBs。）
除非有人有更好的建议;我仍然喜欢听到它：）