# What do these STATE_CREATION warnings mean in the DX11 debug output?

So I've been fighting my way through learning the DirectX 11 API with what little documentation there is out there and noticed some new D3D11 warnings in my debug output. (Atleast I think they are new, been rearranging my draw calls to try and solve another problem I'm experiencing at the moment) Anywho, with some Google-fu I've been unable to find any documentation on the error codes or anything but the general consensus of forums seems to be that the COM objects aren't properly being released.

Now the question is, if that is indeed what the warnings mean, what else do I need to do to kill these things other then call their Release() functions? And is there somewhere this kind of information is posted? I sure can't find it on MSDN or Google. Just lots of confused DX11 post with unanswered questions.

Here is the debug output.

D3D11: WARNING: Live Device: Name="unnamed", Addr=0x004C6488, ExtRef=5 [ STATE_CREATION WARNING #2097297: LIVE_DEVICE ]
D3D11: WARNING: Live Texture2D: Name="unnamed", Addr=0x04552E94, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097235: LIVE_TEXTURE2D ]
D3D11: WARNING: Live Buffer: Name="unnamed", Addr=0x04552A64, ExtRef=1, IntRef=0 [ STATE_CREATION WARNING #2097229: LIVE_BUFFER ]
D3D11: WARNING: Live Buffer: Name="unnamed", Addr=0x04566ECC, ExtRef=1, IntRef=0 [ STATE_CREATION WARNING #2097229: LIVE_BUFFER ]
D3D11: WARNING: Live InputLayout: Name="unnamed", Addr=0x0455280C, ExtRef=1, IntRef=0 [ STATE_CREATION WARNING #2097265: LIVE_INPUTLAYOUT ]
D3D11: WARNING: Live RenderTargetView: Name="unnamed", Addr=0x0455269C, ExtRef=0, IntRef=0 [ STATE_CREATION WARNING #2097244: LIVE_RENDERTARGETVIEW ]
D3D11: WARNING: Live Texture2D: Name="unnamed", Addr=0x04552214, ExtRef=4294967295, IntRef=1 [ STATE_CREATION WARNING #2097235: LIVE_TEXTURE2D ]
D3D11: WARNING: Live Query: Name="unnamed", Addr=0x004C84AC, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097280: LIVE_QUERY ]
D3D11: WARNING: Live Sampler: Name="unnamed", Addr=0x004C8274, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097268: LIVE_SAMPLER ]
D3D11: WARNING: Live RasterizerState: Name="unnamed", Addr=0x004C804C, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097277: LIVE_RASTERIZERSTATE ]
D3D11: WARNING: Live DepthStencilState: Name="unnamed", Addr=0x004C7E24, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097274: LIVE_DEPTHSTENCILSTATE ]
D3D11: WARNING: Live BlendState: Name="unnamed", Addr=0x004C7C6C, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097271: LIVE_BLENDSTATE ]
D3D11: WARNING: Live Context: Name="unnamed", Addr=0x0453006C, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097226: LIVE_CONTEXT ]
D3D11: WARNING: Live Device Child Summary: Device Addr=0x004C6488
Using ID3D11Debug::ReportLiveDeviceObjects with D3D11_RLDO_DETAIL will help drill into object lifetimes. Objects with ExtRef=0 and IntRef=0 will be eventually destroyed through typical Immediate Context usage. However, if the application requires these objects to be destroyed sooner, ClearState followed by Flush on the Immediate Context will realize their destruction.


Note: Clearing and Flushing the device context doesn't seem to affect anything.

Solution

A slight tweak in my code prevented objects from being shut down and releasing their COM objects.

The warnings are informing you of live (unreleased) objects, as you've discovered. Releasing the objects you retain references to is the proper way to clean them up, but you have to release the right objects. There are several ways you can get help tracking down which objects are being retained and from there you can follow the lifetime of those objects through your code and determine where you are missing calls to decrement the COM reference count.

The first thing to do is look at the ExtRef and IntRef columns. IntRef refers to the number of internal references to the object, within D3D itself. These aren't your responsibility to free, but they are an indicator that you're probably holding an external reference to something that is itself holding an internal reference to those objects.

The ExtRef column indicates the number of references that your holding. In this case, you appear to have five outstanding references to the D3D device itself, and the device is probably holding references to all the objects with internal reference counts, leaking them. Tracking down where you need to add additional calls to Release on your device will probably solve most of your problems. You also appear to have outstanding references to some shader and buffer objects.

You can also, as the last line of the output suggests, use the ID3D11Debug interface's ReportLiveDeviceObjects method to get more information on where these objects are coming from and what might be holding on to a reference to them.

Finally, take a look at this post by Chuck Walbourn which details giving your objects unique names to replace the "unnamed" strings in the output, which may also help narrow down the problem.

Without code -- and I presume you have too much of it to reasonably post here -- it's hard to provide more specific direction, unfortunately.

Two other notes:

• The message's talk of clearing and flushing refers to objects with zero internal and external references -- most of the objects in your report wouldn't be cleaned up by doing that, as you've discovered.
• "STATE_CREATION" is one of the predefined message categories used by the D3D11 InfoQueue class. I don't know for sure why this category is used for leak messages instead of the seemingly more appropriate "CLEANUP" category; I suspect it's a bug.
• Wow, thank you! That's a bit much for me at the moment but I'm looking forward to digesting it tomorrow morning when I'm not sleep deprived. Haha. – Joel Jul 9 '11 at 6:35
• @Joel Smith: You should grab a smart pointer and then you will not have any trouble. Boost provides a shared_ptr which will work just dandy given a custom deleter. – DeadMG Jul 9 '11 at 9:53
• @DeadMG: Yeah, I've look at them and using the Boost library. However as stupid as it sounds, I like building my own wheel (and despite what it sounds like I think I'm doing pretty well other than my mass confusion with the D3D11 API) and read the Boost smart pointers can potentially be performance hogs and using handles with handle tables is a safer route. – Joel Jul 9 '11 at 14:29
• I wouldn't consider the Boost pointers performance issues until you have profiled and determined they are in your own application. Once you have figured out your releasing issues, transitioning over to use them would be a great idea. There are other smart pointer options as well. – user1430 Jul 9 '11 at 14:32
• Found the issue. A slight tweak in my hash table nodes was preventing them from calling their shut down procedures. I'll definitely go and take look at the smart pointers. Thanks! Just gotta solve my shader cbuffer problem first... – Joel Jul 9 '11 at 15:04