Error: The Direct3D device has a non-zero reference...

Started by
3 comments, last by 51mon 14 years, 5 months ago
Hi I recently published a demo. I tested it on 3 different machines before and never any error messages of this kind showed up. A couple of people informed me that they got following message: Error: The Direct3D device has a non-zero reference count, meaning some objects were not released. The application runs fine, just the message popped up. I checked that I released everything allocated in the OnD3D9LostDevice and OnD3D9DestroyDevice. (I'm using the DXUT framework and DX9). Does anybody know why this is happening? Anybody else experienced something similar? Is there some good way to debug it, I mean can I output a log on the failing target machine or something? Thanks a lot :)
Advertisement
Quote:Original post by 51mon
Does anybody know why this is happening?
Something is holding on to a reference to the device, because you've not Release()'d something.

Quote:Original post by 51mon
Anybody else experienced something similar? Is there some good way to debug it, I mean can I output a log on the failing target machine or something?
Release() returns the new reference count of the object (But you shouldn't entirely trust it). If Release() on the device is returning a large number (>100 or so, you can do AddRef() then Release() to get the current reference count), then it's probably due to creating an object or increasing the reference count on it on a per-frame basis (E.g. calling GetBackBuffer() every frame and never Release()ing the returned pointer).

If only some machines get it, check your error handling code too, it may be that you only release some resources if particular code succeeds (Again, using GetBackBuffer() as an example, your code could get the backbuffer and Release() it at the end of the function, but not if an error occurs halfway though).
If you can manage to reproduce it on your machine, PIX can tell you which DirectX objects are still alive at the end of your program which should help you in tracking down why they're not being released.
Quote:Original post by Evil Steve
Quote:Original post by 51mon
Does anybody know why this is happening?
Something is holding on to a reference to the device, because you've not Release()'d something.

Quote:Original post by 51mon
Anybody else experienced something similar? Is there some good way to debug it, I mean can I output a log on the failing target machine or something?
Release() returns the new reference count of the object (But you shouldn't entirely trust it). If Release() on the device is returning a large number (>100 or so, you can do AddRef() then Release() to get the current reference count), then it's probably due to creating an object or increasing the reference count on it on a per-frame basis (E.g. calling GetBackBuffer() every frame and never Release()ing the returned pointer).

If only some machines get it, check your error handling code too, it may be that you only release some resources if particular code succeeds (Again, using GetBackBuffer() as an example, your code could get the backbuffer and Release() it at the end of the function, but not if an error occurs halfway though).


The message only appears when the window is resized, but I have gone through the OnD3D9CreateDevice, OnD3D9ResetDevice, OnD3D9LostDevice and OnD3D9DestroyDevice; and can't find any objects that I don't release. I have implemented many projects with DXUT and never experienced this, that's way I'm puzzled. Also, I can't see why the execution would take a different path on some machines, but maybe there is something buried in DXUT?


Quote:Original post by tompko
If you can manage to reproduce it on your machine, PIX can tell you which DirectX objects are still alive at the end of your program which should help you in tracking down why they're not being released.


It only appears on some machines and I don't think I can reproduce it on mine.
Quote:Original post by tompko
If you can manage to reproduce it on your machine, PIX can tell you which DirectX objects are still alive at the end of your program which should help you in tracking down why they're not being released.


So, if I manage to get hold of a machine that produce the error. How do I get PIX to handle that information?

(well, it doesn't have to be PIX, if there is some other way to output the specific object that's fine. I mean, so I can compile a special version and give it to someone with a "failing" machine and it will print the name of the object)


Thanks :)

[Edited by - 51mon on November 6, 2009 11:08:52 AM]

This topic is closed to new replies.

Advertisement