We’re running Blue Iris 6.1.3.10 on Windows Server 2019 with 75 cameras and an Intel UHD 770 GPU. We’ve been experiencing multiple crashes per day. I captured crash dumps using the Windows Error Reporting LocalDumps registry key and analyzed them in WinDbg. I found two distinct crash sites and wanted to share the details in case they’re useful.
Crash 1 — approximately 12:19 PM:
BlueIris+0xd62202: mov dword ptr [r8+r9*8], edx
Access violation writing to a heap buffer. The buffer at r8 = 0x448AF1800 is a live committed heap allocation. At crash time r9 = 0x700 (column 1792) and r15 = 0x780 (width 1920). The write at column 1792 x 8 bytes = offset 14336 past base hit a guard page at 0x448AF5000.
The surrounding disassembly shows this is a pixel compositing loop — reading from three source buffers and combining into RGBA output:
mov edx, [r14+rcx4] ; source A
add edx, [rbx+rcx4] ; source B
add edx, [rbp+rcx4] ; source C
movzx ecx, r8b
shl ecx, 18h
add edx, ecx
mov dword ptr [r8+r98], edx <- CRASH
inc r9
cmp r9, r15
jl -> loop
The frame buffer appears to have been reallocated to a smaller size while this loop was mid-frame, or the dimensions changed during a camera reconnect. The loop continued with the old width value and overran the new buffer boundary.
NonPagedPool was spiking from ~275 MB baseline to 1565 MB in the 90 seconds before this crash, then dropped after BI restarted — consistent with decoder pressure during a mass reconnect event.
Crash 2 — approximately 10:00 AM:
BlueIris+0x7599b2: cmp byte ptr [rcx+3Fh], r13b
Access violation reading through a null pointer. The instruction immediately before the crash:
mov rcx, qword ptr [BlueIris+0x36429b0] ; load global singleton
cmp byte ptr [rcx+3Fh], r13b <- CRASH: rcx = NULL
rcx was loaded from a global/static address (BlueIris+0x36429b0) and was NULL. There is no null check between the load and the dereference. The exception was unhandled — it went straight to UnhandledExceptionFilter with no SEH handler catching it. This looks like a global settings or configuration object that was NULL during a restart cycle while a worker thread was still running.
Environment:
Both crashes appear to be race conditions during camera reconnect events — either a buffer being resized while a compositing thread is mid-frame, or a global object being torn down while a worker thread is still using it. Happy to provide the full dump files if that would help.
Thanks
P.S. Obviously used AI to generate this post but the content is accurate.
Crash 1 — approximately 12:19 PM:
BlueIris+0xd62202: mov dword ptr [r8+r9*8], edx
Access violation writing to a heap buffer. The buffer at r8 = 0x448AF1800 is a live committed heap allocation. At crash time r9 = 0x700 (column 1792) and r15 = 0x780 (width 1920). The write at column 1792 x 8 bytes = offset 14336 past base hit a guard page at 0x448AF5000.
The surrounding disassembly shows this is a pixel compositing loop — reading from three source buffers and combining into RGBA output:
mov edx, [r14+rcx4] ; source A
add edx, [rbx+rcx4] ; source B
add edx, [rbp+rcx4] ; source C
movzx ecx, r8b
shl ecx, 18h
add edx, ecx
mov dword ptr [r8+r98], edx <- CRASH
inc r9
cmp r9, r15
jl -> loop
The frame buffer appears to have been reallocated to a smaller size while this loop was mid-frame, or the dimensions changed during a camera reconnect. The loop continued with the old width value and overran the new buffer boundary.
NonPagedPool was spiking from ~275 MB baseline to 1565 MB in the 90 seconds before this crash, then dropped after BI restarted — consistent with decoder pressure during a mass reconnect event.
Crash 2 — approximately 10:00 AM:
BlueIris+0x7599b2: cmp byte ptr [rcx+3Fh], r13b
Access violation reading through a null pointer. The instruction immediately before the crash:
mov rcx, qword ptr [BlueIris+0x36429b0] ; load global singleton
cmp byte ptr [rcx+3Fh], r13b <- CRASH: rcx = NULL
rcx was loaded from a global/static address (BlueIris+0x36429b0) and was NULL. There is no null check between the load and the dereference. The exception was unhandled — it went straight to UnhandledExceptionFilter with no SEH handler catching it. This looks like a global settings or configuration object that was NULL during a restart cycle while a worker thread was still running.
Environment:
- Windows Server 2019, Intel UHD 770, 20-core CPU, 32 GB RAM
- 75 cameras, all now set to hardware decode: No
- GeForce driver was previously installed and has been removed
- Both crashes occurred after the GeForce removal, so they are not NVIDIA-related
Both crashes appear to be race conditions during camera reconnect events — either a buffer being resized while a compositing thread is mid-frame, or a global object being torn down while a worker thread is still using it. Happy to provide the full dump files if that would help.
Thanks
P.S. Obviously used AI to generate this post but the content is accurate.