Work was coming along quite nicely with the D3D memory leak tracker, but I hit a problem. The embarrassing part is that it only popped up yesterday - its such an obvious use-case that I should've spotted it MUCH earlier.
The backing to my leak checking only knows when the application starts and finishes, the basic principle being that any recorded resources still alive when the application finishes are leaks. But a lost-device scenario is relatively arbitrary and could never happen or could happen lots of times.
I haven't found a particularly graceful way of "hooking" into the Lost-Device call. I'd imagine the only method is via Muhammad's D3D hooking code, that would be a pretty powerful method but is probably going to be a lot of extra complexity.
It also seems that DXUT does some behind the scenes work to help a broken application survive the reset. My leak checker seems to get in the way and brings the whole program crashing down [lol] But I'm hoping thats just a simple bug on my part rather than a design/architecture level problem.
The only thing I've thought of so far today is to require that the application developer add in some sort of manual hook in their OnLostDevice() code. I could expand this to a more generic "check-point" function that can allow the manager to spot leaks much closer to the source, which could be useful...
Whilst this could work its prone to mistakes (e.g. putting it in the wrong place or forgetting it entirely). The best bit about the code I've already got is that it doesn't require many changes to the application's code - its mostly transparent.
Anyone think of any clever ideas? Would having to put a "checkpoint" into your code be a bad thing?