Harmless DXGI warnings with C++ AMP


If you have tried to run C++ AMP program in Visual Studio 2012 on Windows 8 in debug configuration, you might have noticed that after a successful execution there are DXGI warnings reported in the output window. Long story short – there is nothing to worry about; these warnings may be safely ignored. If you are interested in the background, read on for more information.

DXGI_warnings

Fig. 1. Visual Studio 2012 with DXGI warnings visible in the output window.

DXGI

The DXGI acronym stands for Microsoft DirectX Graphics Infrastructure. It is a low-level layer used by DirectX to communicate with the kernel-mode GPU driver. As you may know, C++ AMP implementation provided by Microsoft builds on top of the DirectX stack, thus by extension, on top of DXGI. What is crucial here, is that Windows 8 introduces a new version, DXGI 1.2.

DXGI warnings

When you are working on Windows 8 and running your program in in debug configuration even the simplest code using C++ AMP will result in DXGI warnings being reported in the Visual Studio output window. They will look similar to the following:

DXGI WARNING: Process is terminating. Using simple reporting. Please call ReportLiveObjects() at runtime for standard reporting. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Producer at 0x006C4820, Refcount: 3. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object at 0x006CBB18, Refcount: 3. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object at 0x006E9328, Refcount: 1. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object : 2 [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Process is terminating. Using simple reporting. Please call ReportLiveObjects() at runtime for standard reporting. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Producer at 0x006E9A28, Refcount: 2. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object at 0x006EBE50, Refcount: 3. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object : 1 [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Process is terminating. Using simple reporting. Please call ReportLiveObjects() at runtime for standard reporting. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Producer at 0x00716688, Refcount: 2. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object at 0x00718A00, Refcount: 3. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Object : 1 [ STATE_CREATION WARNING #0: ]

To explain the conditions, reporting “live objects” is a part of the debugging capabilities added to DXGI 1.2. You can register for receiving these messages yourself using IDXGIInfoQueue interface or you can rely on them being printed to Visual Studio 2012 output window, which is automatically enabled when you are using DXGI (and by extension, C++ AMP) in the debug mode.

The reported warnings are last chance messages printed during DXGI shutdown. They include all DXGI objects being alive (meaning not released) at that point of time.

Does it mean that C++ AMP runtime is not freeing these objects? Yes. Is it harmful? No, since:

  1. There is a fixed number of such cached objects (consuming small amount of resources), and their count never goes up during the application lifetime.
  2. The resources associated with these objects are automatically reclaimed by the operating system at process exit.

Diving into a deeper explanation

To go a little deeper, the C++ AMP runtime caches some DXGI objects in its static structures to improve performance. For example this includes IDXGIAdapters underlying Direct3D accelerator objects. At a higher level, both the C++ AMP runtime and DXGI are dynamic libraries, where the first is a dependency of any C++ AMP program and the latter is a dependency of the runtime DLL. So far so good, static dependencies of DLLs aren’t the problem, however the situation complicates a little bit when we add truly dynamically loaded (i.e. using LoadLibrary) libraries to the equation. As it happens, the order of their unloading is not defined against other dynamic libraries. And actually they are quite common in C++ AMP programs, e.g. all driver DLLs are currently dynamically loaded by the DXGI. Going back to the C++ AMP runtime implementation, given that we cannot tell whether our DLL is being unloaded before or after the dynamically loaded driver DLL, we cannot safely release any object from it. But as I explained before, it’s not a problem, since the operating system is going to reclaim it anyway.

One solution would be not to cache DXGI objects. That’s a big no-no for us because caching buys us performance, and we (and you) like performance. The other workaround would be to suppress these messages. Unfortunately there is no way to selectively do so, and we do not want to inhibit this mechanism altogether, as some users might be creating DXGI objects themselves for their own use and might benefit from learning about extraordinary leaks.

Comments (8)

  1. Alan, I understand that this might be a problem for you and some other customers. This blog post is not meant to excuse ourselves, it is just to describe the current situation to the users. As Amit mentioned in the forum thread you are referring to, we do acknowledge it is not desirable and we want to improve it.

  2. Tom Kirby-Green says:

    I do appreciate the transparency around talking about these warnings, they've been bugging me while working with the tech. Please *do* make fixing them a priority, because as it is they stand as broken windows in the product offering and detract from its perceived quality and robustness.

  3. In my humble opinion I would prefer having to initialize and deinitialize this static cache objects which both APIs, something like "AMPInit" "AMPExit", so you can safely control when these objects are instanced and released respectively.

  4. doublenuan says:

    I am wondering why the result of the project is not posted here so that all of us can check our own work.

  5. Christian says:

    Well I get these warnings using Windows 7 and VS 2008, so the given limitations do not apply. Most likely the cause is that one component of our application (MSHTML?) is built using AMP, I guess?

  6. bobyg says:

    @Christian,

    please note that DXGI warning does not mean that the application is using C++ AMP. It is a generic warning and in fact C++ AMP was first released on VS 2012, so if you are using VS 2008 C++ AMP is not the reason for the warning.

  7. IanBoyd says:

    There is a virtue in *not* releasing static resources on shutdown. From Raymond Chen[MSFT](blogs.msdn.com/…/10253268.aspx):

    > The building is being demolished. Don't bother sweeping the floor and emptying the trash cans and erasing the whiteboards. And don't line up at the exit to the building so everybody can move their in/out magnet to out. All you're doing is making the demolition team wait for you to finish these pointless housecleaning tasks.

    > All this anal-rententive memory management is pointless. The process is exiting. All that memory will be freed when the address space is destroyed. Stop wasting time and just exit already.

    > Don't worry about freeing memory; it will all go away when the process address space is destroyed. Don't worry about closing handles; handles are closed automatically when the process handle table is destroyed. Don't try to call into other DLLs, because those other DLLs may already have received their DLL_PROCESS_DETACH notifications, in which case they may behave erratically in the same way that a Delphi object behaves erratically if you try to use it after its destructor has run.

    > I regularly use a program that doesn't follow this rule. The program allocates a lot of memory during the course of its life, and when I exit the program, it just sits there for several minutes, sometimes spinning at 100% CPU, sometimes churning the hard drive (sometimes both). When I break in with the debugger to see what's going on, I discover that the program isn't doing anything productive. It's just methodically freeing every last byte of memory it had allocated during its lifetime.

    You want to make sure you are not leaking memory during run-time. Fine. These notifications are noise that make your like harder. Yes.

    But **don't** go hunting down every last byte you've allocated during your lifetime just so you can free it. You're wasting my hard drive I/O, you're wasting my CPU, you're wasting my battery, you're wasting my time.

    You can free everything on shutdown; as long as you don't use shutdown as the time to free things.