CNA-BUG-101: GraphicsDevice::Reset rolls back only the window and virtual-resolution stage; a later renderer failure leaves the new PresentationParameters stored and DeviceReset unraised

CNA snapshot 009d40f5  ·  Known Issues › Current bugs  ·  source links pinned to 009d40f5

An exception from UpdatePresentationFormatEXT, ApplyMultiSampleCount or SetSwapInterval escapes after the new parameters are stored and render targets were unbound, and after DeviceResetting was raised, so the device reports settings it may not have applied.

Identifier

CNA-BUG-101

Category

Bug

Subsystem

Graphics & renderers

Status

Open

Verified against

CNA 009d40f5 (009d40f5dd085c4e674d3479675fac84b12b3e0a)

Severity

Low (a triage suggestion, not a project priority)

Evidence basis

Source-verified: read at TARGET, not executed

Tests touching this area

Yes: see Current tests

Affected contract

Microsoft::Xna::Framework::Graphics::GraphicsDevice::Reset(const PresentationParameters&, GraphicsAdapter*) and its three shorter overloads

Expected behaviour

XNA 4.0's GraphicsDevice.Reset (read from the decompiled IL) copies the new PresentationParameters into its cached and public parameter objects only after the native reset succeeded, so a failed Reset leaves the previous values reported; on failure XNA raises DeviceResetting and throws without raising DeviceReset. CNA's own REMED-GFX-029 comment states the same intent for the window and resize stage: "a renderer resize is a failed Reset, not a partially successful one", with all public presentation bookkeeping restored before the exception is rethrown.

Actual behaviour at TARGET

In GraphicsDevice.cpp only applyPresentationParametersToWindow() and SetVirtualResolution() are inside the rollback try. The following renderer calls - UpdatePresentationFormatEXT, ApplyMultiSampleCount and SetSwapInterval - run after presentationParameters_, adapter_, the virtual size and the touch-panel size were replaced and after any bound render targets were unbound. If one throws (Direct2D's ApplyMultiSampleCount, for example, throws NotSupportedException for a requested count above 1, which PreferMultiSampling requests as 8; its UpdatePresentationFormatEXT refusal of a non-Color back buffer or non-None depth cannot fire here, because Reset first normalises both formats through the renderer's applied-format hooks), the exception escapes with the new values stored, so the device keeps reporting presentation parameters, adapter and virtual size that the renderer rejected. The missing DeviceReset after DeviceResetting and the unrefreshed viewport are what XNA's own failed Reset does; the divergence is the stored state.

Source locations

• modules/graphics/src/Xna/GraphicsDevice.cpp — GraphicsDevice::Reset(const PresentationParameters&, GraphicsAdapter*) rollback try-block and the renderer calls after it

Evidence

Checked by reading the named sources at 009d40f5; nothing was built or executed for this entry.

Independent re-verification: Checked by reading the named sources at 009d40f5 and XNA 4.0's decompiled GraphicsDevice.Reset; nothing was built or executed. The regression test should assert that PresentationParameters, adapter and virtual size are unchanged after a later-stage failure; it should not require DeviceReset to be raised, because XNA does not raise it.

Focused reproduction

No focused reproduction is known. Nothing has been invented here; the evidence above is what exists.

Current tests

Reset tests cover the resize-stage rollback; no test injects a failure into the later stages.

Regression test

A HEADLESS or STUB test renderer whose ApplyMultiSampleCount throws, asserting that PresentationParameters is unchanged afterwards (or that DeviceReset/Resetting stay paired, whichever contract is chosen).

Blast radius

Games that change back-buffer format, depth format or multisampling at run time on a renderer that refuses the new value; the device then reports the rejected settings.

Workaround

Query renderer support (capabilities, format queries) before requesting a change.