[REGRESSION] Painter 12.0+ crashes on project init with RTX 4090 — 11.1.3 stable, 12.0.0/12.0.3/12.1.2 all crash

Failure.Bucket:
INVALID_POINTER_READ_c0000005_nvoglv64.dll!Unknown

ExceptionCode: c0000005

Attempt to read from address 0000000000000188

STACK_TEXT:
nvoglv64!vkGetInstanceProcAddr
RTSSHooks64!ValidateRuntimes
RTSSHooks64!ValidateRuntimes
RTSSHooks64
RTSSHooks64
RTSSHooks64
Adobe_Substance_3D_Painter

Update: Root cause identified and issue resolved.

Substance 3D Painter 12.1.2 was consistently crashing on my main Windows profile but worked correctly on a second Windows user profile.

After ruling out Painter preferences, cache, custom assets, user environment variables, and the project itself, I captured the failure with ProcDump and analyzed the dump in WinDbg.

The exception was:

C0000005 ACCESS_VIOLATION

Failure.Bucket: INVALID_POINTER_READ_c0000005_nvoglv64.dll

MODULE_NAME: nvoglv64

IMAGE_NAME: nvoglv64.dll

The relevant stack showed:

nvoglv64.dll
RTSSHooks64!ValidateRuntimes
RTSSHooks64.dll
Adobe Substance 3D Painter.exe

Painter also had the RivaTuner Vulkan layer loaded:

RTSSVkLayer64.dll

RivaTuner Statistics Server 7.3.7 was installed alongside MSI Afterburner 4.6.7 Beta 2.

I disabled MSI Afterburner/RTSS startup and disabled the RTSS Vulkan implicit layer. I then verified that neither RTSSHooks64.dll nor RTSSVkLayer64.dll was loaded inside Painter.

After removing RTSS from the Painter process, the same project and the same actions that previously caused the crash worked normally with no crash.

Conclusion: the crash was caused by an interaction between RivaTuner Statistics Server's hooks/Vulkan layer and the NVIDIA graphics driver while running Substance 3D Painter.

Painter is now stable with RTSS disabled/removed.

Correction to original post

The original title/post is now outdated. Further testing has shown that Painter 11.1.3 Build 5196 is also reproducibly affected, so this is not limited to Painter 12.x.

The crash has now reproduced across Painter 11.1.3 and 12.x, multiple NVIDIA driver versions, and even after a full DDU removal in Windows Safe Mode followed by a fresh offline Studio 591.74 installation.

Please refer to my later replies for the updated crash signatures, VRAM findings, and troubleshooting results. The current working theory is a broader Painter/NVIDIA graphics-stack or resource-management issue rather than a simple 12.x regression.

Additional test — full NVIDIA driver removal with DDU in Safe Mode

I also performed a full NVIDIA driver cleanup using Display Driver Uninstaller (DDU) in Windows Safe Mode.

Procedure:

• Disconnected the PC from the internet
• Booted Windows into Safe Mode
• Used DDU to completely remove the NVIDIA display driver
• Rebooted normally while still offline
• Installed NVIDIA Studio Driver 591.74 from scratch using Custom / Clean Installation
• Rebooted again before testing Painter

NVIDIA Control Panel subsequently confirmed the RTX 4090 was running driver 591.74 correctly.

Result: Painter still crashes.

The post-DDU Painter 12.1.2 log also confirms that Painter detects the RTX 4090 correctly, sees 24,138 MB VRAM, and considers driver 591.74 supported and not outdated.

This makes residual/corrupted NVIDIA driver files from previous installations substantially less likely as the explanation.

One additional observation: this particular post-DDU crash did not generate the usual matching Event Viewer Application Error entry. Painter displayed its own crash reporter instead. The application log terminates abruptly after normal initialization/shader creation rather than recording an explicit GPU-device-lost or Vulkan error.

Same issue since 11.0.2. Painter crashes after long loading, sometimes even rendering the whole scene before giving “bad allocation” error and crashing. On 12.1.2 it just straight up shows crash report window after loading.

It’s a 3.6 GB project with many high-poly meshes and a custom OCIO config. Crashes only happen loading the project no the smaller ones.

Strangely, I found breaking the OCIO path, where Painter prompt a new OCIO path (and give it), actually allow the project to be fully open without issue.

RTX 40 series GPU, latest Studio Driver. 64 GB RAM.

Edited for more info.

Since my last update, continued testing has produced two findings that materially change the scope of this issue. I am documenting them for engineering review.

1. Painter 11.1.3 Build 5196 is now reproducibly affected

Painter 11.1.3, which initially appeared stable, is now repeatedly crashing with the following signature:

• Faulting module: nvoglv64.dll
• Exception code: 0xc0000409
• Example fault offset: 0x10907fd
• NVIDIA driver: 32.0.15.9174 / 591.74

This means the issue is not isolated to Painter 12.x. Painter 11.1.3 is now reproducibly affected on the same system.

2. Very high surface-memory allocation is reported before the crash

With the affected shoe project open, Painter reports approximately:

• VRAM Surfaces (Results & Sources): 22.47 GB
• Result Surfaces (RAM & VRAM): 44.95 GB
• Source Surfaces (RAM & VRAM): 11.24 GB
• Physical VRAM detected by Painter on the RTX 4090: 24.14 GB

Painter successfully opens the project and can remain interactive for some time. The crash can then occur during an ordinary operation such as creating a simple layer, rather than during project loading.

Given the reported surface allocation immediately below the physical VRAM capacity, this behavior appears consistent with a possible GPU resource-allocation, resource-accounting, or memory-management issue. I am not asserting that VRAM exhaustion itself is the cause, but I believe the allocation figures warrant engineering investigation, particularly in conjunction with the repeated nvoglv64.dll / 0xc0000409 failures.

Troubleshooting already completed

The issue has persisted after testing:

• XMP enabled and disabled (DDR5-5200 and DDR5-4000)
• Extended Windows TDR timeout (60 seconds; subsequently restored to default)
• Full Painter preference/cache reset
• NVIDIA shader-cache cleanup
• Minimal/background-GPU-process testing
• SVT hardware acceleration enabled/disabled
• Adobe sample content in addition to user projects
• NVIDIA driver versions 591.74, 596.36 and 610.88
• Painter 11.1.3 as well as Painter 12.x

Requested engineering review

1. Please review Painter's surface/VRAM accounting for this workload and determine why approximately 22.5 GB of VRAM surfaces are being reported on a 24 GB RTX 4090.
2. Please investigate the nvoglv64.dll / 0xc0000409 crash path, particularly during texture/layer resource creation or updates when Painter is reporting high GPU-memory utilization.
3. Please determine whether this corresponds to a known Painter/NVIDIA resource-management issue or defect.

I can provide the complete Painter logs, Windows Event Viewer records/crash dumps, DxDiag, and affected project file for reproduction.

Reducing the project to 1024 textures would be useful as a diagnostic A/B test, but I would not consider it an acceptable resolution to the underlying issue. The workstation uses an RTX 4090 with 24 GB VRAM and 128 GB system RAM, and the workload should be investigated to determine why Painter is reaching this allocation level and subsequently crashing.

Addendum — Updated findings for escalation 

Since my last update, continued testing has produced two findings that change the scope of this issue. I am documenting them here for engineering review.

1. Painter 11.1.3 Build 5196 is now reproducibly affected

Painter 11.1.3, which initially appeared stable, is now crashing with the same signature as 12.x:

• Faulting module: nvoglv64.dll

• Exception code: 0xc0000409 (STATUS_STACK_BUFFER_OVERRUN)

• Example fault offset: 0x10907fd with NVIDIA driver 32.0.15.9174

This eliminates the "version-specific regression" theory. The crash is not unique to Painter 12.x. It is a persistent failure in the Painter/graphics-driver stack that can be triggered across major versions.

2. VRAM allocation approaches physical limit before crash

With the shoe project open, Painter reports:

• VRAM surfaces: ~22.47 GB

• Total surfaces (RAM + VRAM): ~44.9 GB

• Physical VRAM on RTX 4090: ~24.1 GB

The project opens successfully and remains interactive. The crash occurs during routine operations (e.g., adding a layer) — not during load. This pattern is consistent with a memory management or resource-accounting failure: a small additional allocation pushes the stack over an edge case in the NVIDIA OpenGL path, triggering 0xc0000409.

What this means

This is no longer a user-configuration issue. The following have been ruled out:

• RAM/XMP instability (tested at DDR5-4000 and DDR5-5200)

• Windows TDR (tested at 60s, restored to default)

• Painter preferences/cache corruption (fully reset)

• NVIDIA shader cache (cleaned)

• Background GPU processes (tested in isolation)

• SVT hardware acceleration (tested on/off)

• Project-specific corruption (reproduced with Adobe sample content)

• Single driver version (reproduced across 591.74, 596.36, and 610.88)

What I need from Adobe Engineering

1. Analysis of Painter's VRAM accounting on this workload. Why does a standard project allocate ~22.5 GB of a 24 GB budget?

2. Investigation of the nvoglv64.dll crash path to determine if Painter is passing invalid buffer parameters when near the VRAM limit.

3. A determination of whether this is a known memory-management defect.

I am prepared to provide full application logs, Windows crash dumps, and the project file on request. I will not accept "reduce texture resolution to 1024" as a resolution. This workstation is explicitly within Painter's stated hardware capabilities.