Leaky D3D Resources and Anti-Tamper Code Capcom Needs to Send Back to Hell

reference counts are growing out of control and in some cases the driver is resetting itself after just a few frames!

First and foremost, remove Denuvo or at least only apply it to DRM.

Whatever reason you have for protecting non-DRM code with Denuvo, you might want to re-evaluate.

"World Anti-Tamper" is tripping over Ansel's whitelisting DLL, GeForce Experience's overlay, the Steam overlay........ these are things your customers have pre-installed and Denuvo is blowing the software out of existence on normal users systems the same as it would if some illegitimate user were actually trying to sugically remove the game's DRM code.

I have modified countless dozens of Denuvo-protected games, this is the only one with problems like this and it would be irresponsible of me not to push this issue HARD. I may well be the only person observing these problems with the proper context to know what is causing them.

You are actually hurting your customers in very tangible ways that do not revolve around the usual "what-if" Denuvo scenario people spend too much time obsessing over. Your game does not run on many systems well in advance of Denuvo's activation servers disappearing.

Is this this what we are supposed to expect when Capcom uses Denuvo? Some kind of race between Denuvo flipping out over a user's new driver and the eventual shutdown of servers? If it is, you should know ... NVIDIA already won this race on launch day, and even Valve has crossed the finish line as I have now witnessed the Steam overlay's injected code tangle with "World Anti-Tamper" code paths and send Denuvo into ragequit.

Is this really an effective use of your developers time or your customers money?

I am not a monster :)

Those functions have to be atomic and memory coherent, and this is a very common mistake that produces exactly the behavior I am seeing.

I am very concerned by (D3D11) resource leaks I have found in the latest patch, probably not for the reason you would expect. I do not have a good feel for how much memory is being leaked here, the more immediate problem is that once you have lost track of even a single resource in D3D11 memory it is impossible to safely use fullscreen mode.Generally you can resize the framebuffer in full screen mode without releasing all memory first, what you cannot do is change into and out of HDR mode. That involves changing the swapchain's pixel format, and that requires you to teardown all of your resources, change the colorspace and then reload everything. All these DXGI errors you are bombarding users with are the result of flubbed up reference counting code in the engine.The behavior I am seeing when attempting to validate reference counting behavior on textures created by the engine is that every time I request a single reference the memory's reference count increases by more than one. That'd be okay-ish if removing a single reference decreased the counter by the same exact number.But it is not:If I may offer some general advice (and some important criticism):Clearly the biggest threat here is not server availability, but rather parts of the store actually selling your software and the hardware infrastructure required to run it.NVIDIA has already thrown a number of compatibility problems at you as fast and hard as they can and they are very eager to continue bundling even more compatibility problems (features?) into their driver install as time goes on -- this is basically what defines PC gaming, never-ending bloat and compatibility issues. You have opted to nail your software down so hard that your anti-tamper solution is already picking fights it cannot win with the biggest and most important hardware vendor on the platform.I implore you to remove the anti-tamper code that is already killing your software. The choice is ultimately yours what you intend to do about this problem, but it is a problem unique to your software. I can assure you people will notice this, you will be singled-out, and from personal experience there is a really unethical side to PC gaming that you are better off ignoring rather than inciting. They will not leave me the hell alone and in my case there is no truth to anything they are saying, it will be monumentally worse for you if there is a shred of turth for them to rip their claws into.I have been and will continue to use this game as a preeminent example of negligence in the pursuit of software "protection".I'd focus a cursory investigation on any COM wrappers you have written or recently introduced. More to the point, ensure that you have not forgotten the necessary memory barriers (InterlockedIncrement and InterlockedDecrement rather than ++ or --) to make AddRef and Release thread-safe.