For anyone who stumbles onto a similar issue in the future:
The article @balachandran_c was very useful in figuring out that the original issue had to do with dynamic memory allocation in a Win32 application being limited to ~1.75GB, which makes sense as I was seeing the crash at around the ~1.7GB mark, due to the fact that I was creating surfaces for each new frame that arrived. Switching to a Win64 application should push that memory limit to ~3.75GB. Combining this with an SSD to improve IO speeds should allow me to dispatch the surfaces at a rate close to those which they’re being received.
Trying to build for x64 caused a separate issue. The build would fail at the outset, no stack trace etc, with an Error stating:
“This application was unable to start correctly (0xc000007b). Click OK to close the application.”
The error indicates an invalid image format. Basically the Cinder Block at fault was trying to run 32bit DLLs for the 64bit build. The reason the error was hard to diagnose was that the xml file for the block was setup incorrectly, causing the Post-Build event in VS’s configuration properties > Build Events to execute the Command Line commands to copy the DLLs from the incorrect location, ie Win32 as opposed to Win64.