Debugging DX9 memory leaks

1. D3D uses its own heaps so your own memory diagnostics won't help you much.


2a. D3D leaks are COM object leaks rather than memory leaks in the traditional sense.

2b. CComPtr in ATL can help ensure every created COM object pointer is released properly.

2c. For debug purposes, you can look at the return code from ->Release() to see which objects still have references.

2d. Any D3D Get*() call that returns a COM object incremements the reference count; make sure you Release() for each reference.

2e. Some D3D Set*() calls that bind one object to another (e.g. texture to a device); the docs for those calls usually detail how to unbind/decrement the reference count (for example in the case of SetTexture(), passing a NULL texture unbinds the currently set texture so decrementing its reference count).


3. For most D3D debugging and diagnostic work, PIX is your friend. Record all D3D and D3DX calls made by your app. Then in the recording, go to the last entry where the device and D3D objects are released. Take a look at the Objects pane/tab, there you can see which objects are still 'alive' at the point of app shutdown and how many references there are to them. For texture and geometry resources, you can use PIX to look into the contents of that resource which can be a very quick way to track down what's leaking ("aha, that's my font texture...")

Additionally, you can go to the DirectX control panel and set "Break on AllocID" to the allocation ID of one (ideally the first, as these things tend to cause cascading leaks) of the reported objects. The allocation ID should be in there somewhere, although it can be tricky to find alongside the rest of the debug spew.

This will cause the D3D runtime to trigger a breakpoint during the allocation of that particular object, which will help you track it down. This is most useful if you are running a deterministic simulation (that is, the program runs so that it allocates everything in the same order each time, so the IDs remain the same across runs).

Thanks S1CA, that's exactly what I wanted to know. PIX? Right. Got it!