Two problems with rendering to WAV file (stoppage)

I'm having two problems when I try to render a project to a wav or mp3 file.
First my stats:  Windows 10 64-bit,  Intel i7-5820K CPU @ 3.30GHz, with 32 GB of Ram

Problem 1: Most common -  While I'm rendering a project down to a wav file, I'll often get "Audio Dropout: The audio engine has been stopped unexpectedly"  (See image below).  Which is not a big problem since the rendering will continue and create a proper wav file.  After rendering, I simply restart the audio engine.  But I'm curious as to why this is occurring.  It may have something to do with:

Problem 2:  This is a fairly new problem and it DOES cause a work stoppage.  Again, refer to the image below, the rendering will stop either halfway through (Fast bounce = No)  or almost immediately as soon as I start the render.
I experimented with a few things and have figured out a workaround, although I don't think this should be happening on the PC I'm using, it's not the most powerful computer, but it's not weak either.

My project was set at Sample Rate 48,000, with Bit Depth at 24.  The wav rendering I was trying had the settings for a CD, which is Sample Rate= 44000 and Bit Depth = 16. That's when the rendering would stop.  I tried a few different variations, I lowered the projects sample rate to 44,000, but that still caused a stoppage.   When I also changed the render settings to match the projects Bit Depth (24), I was able to complete the render without any stoppages.  The dithering was set to Pow-r 2.

So I'm guessing, since this project is a bit larger than my normal projects (8 minutes long and 6 VST plugins (all frozen), along with three vocal tracks, each one had Melodyne applied to the entire tracks (also bounced/frozen), that my computer was struggling with the conversion of Sample Rates and Bit Depths.  When I matched the output settings of the wav file to the project settings, it worked okay. 

Also something new, I'm using the new version of Izotope Ozone 8.  But even after disabling that in the master bus, the stoppage still occurred.  (Still, I thought I would just mention that)

So unless anyone has any other suggestions, my guess would be to create all my projects using 44,000 and 16 since my final files are either going to be put on a CD, or an MP3 at 256 uploaded to SoundClick.  But I've read that having your project settings set at 48000 and 24 can make the higher frequencies (cymbals, and synths) sound less harsh.  That's the only reason I don't start each project with the normal CD settings of 44,000 and 16.

Thanks for any suggestions or insights,
Lee

Hi. You should have no issues using 24/48. More headroom in 24 bit than 16, so I'd continue using that.
Do you have any unrendered clips that might be causing the Audio Engine to struggle? Any archived or hidden tracks?
Have you tried increasing the ASIO buffer to 2048? I recall reading that Ozone 8 is quite resource hungry.
All the best.

i would also try rendering without ozone8 in the project, quicker to check than a rollback

yeah sorry, i meant actually delete it from the project, not just disable it

Sorry this is getting so complicated.  I originally wanted to know if anyone was experiencing this problem with the latest version.
In the last test I did that failed, with the latest version, it failed when I opened up my web browser (while Sonar was rendering) to post in this forum.   I tried it again, same settings, same version, without opening my browser (something I used to be able to do in the past) and the rendering made it all the way through this time.

So it seems my computer is just on the verge of being able to process and render this project, but it only takes one application or one efx to send it over the edge and crash.
I'm not sure why this is happening more recently.  My computer specs are well beyond the minimum requirements.
But I guess it's a combination of things that are making my computer just barely able to get through the rendering of this project.   It could be my D drive is getting too full.  It's a 1TB HDD and it's 3/4 full.   So I might try uninstalling a bunch of non-DAW related files and see if that helps.

scook
The buffer problems could be the result of NOT using fast bounce. It is difficult to determine from the OP if fast bounce is always off. Also, instead of turning off Ozone, try bypassing the FX bin (the option is in the FX bin context menu). Although, I would try fast bounce first.
 
Have you tried bouncing to a stereo track in the project and exporting just that track?

So you're saying it's better to use fast bounce when rendering a project down to a stereo wav file?
I've never used the fast bounce in rendering an entire project, only on individual tracks.

I'll also try bouncing to a stereo track, and exporting that.  But when creating an MP3 file, I find it's easier and quicker to do it as an "Export audio" function.

Leee
I'll also try bouncing to a stereo track, and exporting that.  But when creating an MP3 file, I find it's easier and quicker to do it as an "Export audio" function.

What works is the quickest method. I only suggested the bounce to get past the problems in the current process. It it still possible to export as mp3. Of course an mp3 export creates a wav file as part of its process.
 
Also considerAud.ini which probably was added to my post after you read it.

The dropouts could be caused by memory exhaustion. Try turning off the 64-bit option in the export dialog. That will greatly reduce the amount of memory used during exporting.
 
I don't believe there is any difference in memory usage between slow and fast bounces. The biggest difference is that fast bounces don't care about CPU load or audio buffer size. It just slows down if necessary, which is why a "fast" bounce can sometimes actually be slower than a "slow" bounce, a phenomenon I'd witnessed many times on my old CPU-challenged machine. (Audible bounces are another matter, and much more prone to "dropouts" due to the added overhead of writing to disk whilst filling audio buffers.)