Summary
OctaneRender for Cinema 4D crashes consistently during batch rendering due to a null pointer dereference inside the OIDN 2.3.3 CUDA module that is statically linked into octane.dll. The denoiser is fully disabled in render settings. The OIDN code path executes regardless of user configuration, processes bad floating-point data, and brings down the entire Cinema 4D process. This bug has been reported privately months ago with no fix. It persists across plugin versions 2026.2 (1.9.0) through 2026.4 (1.9.5).
Environment
Component Detail
Octane Plugin OctaneRender Studio+ for Cinema 4D, versions 2026.2-1.9.0 through 2026.4-1.9.5
Octane DLL OctaneRender Studio+ 2026.2 15010000 / 2026.4 15030000
Cinema 4D 2026.103 (build 10)
OS Windows 10 Pro x64, build 19045
CPU AMD Ryzen (AuthenticAMD, family 15, model 1, stepping 2) — 32 cores, HT — 4.5 GHz
GPU 0 NVIDIA GeForce RTX 5090, 32 GB VRAM, compute 12.0
GPU 1 NVIDIA GeForce RTX 3090, 24 GB VRAM, compute 8.6
Driver NVIDIA 591.74 (r591_66)
RAM 256 GB
Network render slaves 3 nodes (UONVISUALS, CORNERBOTTOM, UONMINI)
Denoiser Settings
All denoiser options are disabled in the Octane render settings. This crash is not caused by a user-enabled denoiser. The OIDN CUDA code path is being invoked internally by the Octane engine regardless of what the user has configured. I have tried every combination of denoiser-related settings I can find — the crash persists because the code path is unconditional.
Additionally, because the OIDN module is statically compiled into octane.dll (not loaded as a separate DLL), there is no way for a user to prevent the code from loading. Environment variables like OIDN_DEFAULT_DEVICE=cpu and OIDN_DEVICE_CUDA=0 have no effect.
Crash Details
Faulting Thread Call Stack (identical across all crashes)
octane.dll: Octane::isGreyscalePass + 0xd27ad0 ← CRASH (null pointer dereference)
octane.dll: Octane::isGreyscalePass + 0xd2c21e
octane.dll: Octane::isGreyscalePass + 0xd2da67
octane.dll: oidn_init_module_device_cuda_v20303 + 0x77e277
octane.dll: oidn_init_module_device_cuda_v20303 + 0x77d563
octane.dll: oidn_init_module_device_cuda_v20303 + 0x770414
octane.dll: oidn_init_module_device_cuda_v20303 + 0x7802f5
octane.dll: oidn_init_module_device_cuda_v20303 + 0x7815d9
octane.dll: oidn_init_module_device_cuda_v20303 + 0x78178b
octane.dll: oidn_init_module_device_cuda_v20303 + 0x1eaa83f
KERNEL32.DLL: BaseThreadInitThunk + 0x14
ntdll.dll: RtlUserThreadStart + 0x21
Key Register State at Crash
rcx: 0x0000000000000000 ← NULL pointer being dereferenced
rdx: 0x0000000000000280
rax: 0x0000000000000280
r12: 0x0000000000000000
r13: 0xffffffffffffffff
The rcx register is null. This is the pointer the OIDN CUDA filter kernel is trying to read from. It is a null buffer pointer — either an unallocated denoiser input/output buffer, or a CUDA device pointer that was never initialized.
MXCSR (Floating-Point Status)
Crash 1: MxCsr = 0x1fb3 (Invalid Operation + Denormal Operand flagged)
Crash 2: MxCsr = 0x1fb2 (Invalid Operation flagged)
The Invalid Operation exception flag confirms the OIDN kernel encountered NaN or denormalized floating-point values before crashing. This suggests the denoiser received corrupt or uninitialized pixel data as input.
Crash Reproducibility
Crash Plugin Version Date Same Stack?
1 2026.2-1.9.0 2026-04-11 Yes — identical offsets
2 2026.4-1.9.5 2026-09-09 Yes — identical offsets
3 2026.4-1.9.5 2026-09-10 Yes — identical offsets
The crash addresses, function offsets, and register patterns are identical across all instances. This is the same bug, unfixed across at least two major plugin releases spanning five months.
Technical Analysis
1. The OIDN CUDA module runs unconditionally
The function oidn_init_module_device_cuda_v20303 is Intel Open Image Denoise 2.3.3, compiled for the CUDA backend. This code is statically linked into octane.dll — it is not a separate DLL that can be removed, renamed, or disabled via environment variables.
The crash occurs on a dedicated render thread (not the main thread, not a Cinema 4D worker thread), meaning Octane is spawning its own OIDN processing thread during rendering. Because the denoiser is disabled in user settings, this thread should not be running at all. Either:
(a) The denoiser setting is not being checked before the OIDN pipeline is invoked, or
(b) An internal Octane subsystem (e.g., adaptive sampling, the camera imager, or tonemapping) invokes OIDN regardless of the user-facing denoiser toggle.
2. The null pointer is a CUDA device buffer
The crash dereferences rcx = 0x0 inside what appears to be an OIDN CUDA filter kernel dispatch. The surrounding registers (rdx = 0x280, which is 640 — likely a buffer stride or tile width) suggest this is a tiled image processing operation where one of the input or output device pointers was never allocated on the GPU.
This is consistent with an initialization-order bug: the OIDN filter object is created and the kernel is dispatched, but the CUDA buffer backing the filter's input image was never allocated (because the user disabled denoising, so no buffer was prepared — but the filter runs anyway).
3. Multi-GPU configuration may be a contributing factor
The system has two GPUs with different compute capabilities (RTX 5090 = sm_120, RTX 3090 = sm_86). In the Octane log, both GPUs show as enabled (<En>) during the crash sessions. OIDN's CUDA backend selects a device at initialization — if it selects one GPU while Octane's render buffers are allocated on the other, the device pointer would be invalid (effectively null from the perspective of the wrong CUDA context).
This was tested with the RTX 3090 disabled. The crash still occurs on the 5090 alone, but the multi-GPU path may be an additional trigger.
4. Data corruption observed in the same session
The Octane log from the crash session also contains:
[2026-09-10 00:13:03][Error][Render]chunk 4 is not a valid compressed chunk
This compressed-chunk error appeared immediately before the crash, suggesting the OIDN module may be receiving corrupted data from the render pipeline or from network render slaves.
Additional Crash: Null Node Pin Access (Separate Issue, Same Root Instability)
A prior crash on the same system (2026-04-11, plugin version 2026.2-1.9.0) showed a different failure mode inside octane.dll:
[Error][Render] Tried to access null node pin
[Error][Render] Tried to access pin via an invalid index 5
[Error][Render] Tried to access pin via an invalid index 2
[Error][Render] Tried to access pin via an invalid index 4
This is a separate bug (node graph corruption rather than OIDN), but it demonstrates a pattern of null-pointer and bounds-check failures in the Octane plugin. Both crash types result from the plugin failing to validate pointers and indices before use.
What User Has Already Tried (None of These Fix It):
- Disabled every denoiser option in Octane render settings (Spectral AI, OIDN, all of them)
- Set Windows environment variables OIDN_DEFAULT_DEVICE=cpu and OIDN_DEVICE_CUDA=0 — no effect because OIDN is statically linked
- Searched for separate OIDN DLLs to rename — they don't exist; the code is inside octane.dll
- Disabled the RTX 3090, rendering only on the RTX 5090 — crash still occurs
- Updated from Octane 2026.2-1.9.0 to 2026.4-1.9.5 — same crash at the same code offsets
- Reported this issue privately months ago — no fix, no acknowledgment in changelogs
What OTOY Needs to Do
- Add a null-pointer check before dispatching the OIDN CUDA filter kernel. The crash is a null dereference of rcx at Octane::isGreyscalePass + 0xd27ad0. A single pointer validation before the kernel dispatch would prevent the crash entirely.
- Respect the user's denoiser setting. If denoising is disabled, the OIDN filter object should never be created, the CUDA buffers should never be allocated, and the processing thread should never be spawned. Currently, the OIDN pipeline runs regardless of configuration.
- Validate CUDA device pointers when multiple GPUs are present. If the OIDN filter selects a different CUDA device than the one holding the render buffers, the device pointer will be invalid. This must be checked before kernel dispatch.
- Handle denormalized/NaN pixel data gracefully. The MXCSR flags show Invalid Operation and Denormal Operand were raised before the crash. The OIDN input buffers should be sanitized (clamped, NaN-replaced) before being passed to the filter, or OIDN should be configured with setFilterQuality to handle edge cases.
_BugReport.txt — Full Cinema 4D crash report with complete thread dumps (crash 1, 2, and 3)
c4doctanelog.txt — Complete Octane render log showing device configuration, render progress, and the chunk is not a valid compressed chunk error
_BugReport.prf, _BugReport.c4d_prf, _BugReport.l4d — Cinema 4D profiling data from crash sessions
threads.dump — Thread profile dump at time of crash
(I will send these in a private message)
All crash dumps show the identical call stack in oidn_init_module_device_cuda_v20303 within octane.dll.
This is a crasher bug in shipping software that has been present for at least five months across multiple plugin releases. It cannot be worked around by the user because the crashing code path ignores user settings and is embedded in the plugin binary. Please prioritize a fix.