I’ve started to experience this too on projects of different sizes, also if i use offline export the gui does not update and i cannot cancel out of the mixdown, i have to wait for it to complete.
I also started getting a nag screen from my gpu that there is a driver update so i’ll give that a go later on and report back… also this seem to work better if i export from the start of the track and leave a bar or two of pre roll…
Hi,
Just finished extensive test on this and am sure it is a BUG. 
6 midi Steinberg product vst tracks 38 bars long.
Right locator on 39.
Left locator moving progressively from 1 to 38.
Set to 48k, 32bit float.
Real time export worked on some bar locations but not others.
Not working on :-
9
21
22
23
24
26
27
28
29
30
31
32
Worked on all other bar locations.
This must be a BUG.
Please could someone else try the same test.
Regards
Mike001
Grrrrrr i’m getting so annoyed as this Disk Overload Error. 
It’s really wrecking my workflow as I simply can’t bounce any tracks that use hardware in them thus need a realtime bounce. I have to move the part to an empty part of the project, then bounce it, then go back and put it where I want.
I wish I could just bounce a whole track in realtime, never mind just parts in situ.
I’m bouncing to a 500mb/s Samsung SSD, so it’s certainly not a drive speed issue, and my average-processing load meter is only about 50%. (i7 4790k @ 4.8ghz)
I really hope this issue gets looked at, there must be something wrong with C8 to generate this many issue reports.
Well after updating the Video driver the meter works. I still get overload errors using hardware but if I set latency very high I can usually get through a mix.
Kenny
push
well…
i moved to windows 10 and have cubase in the latest version installed and a samsung ssd as well…
no chance to export in real time…
and i have to because of virus ti…
what i observed is that when your track is in stop and you just click somewhere on the timeline to move the playbar to that position, the disk cache load meter peaks for a short time. i think this has something to do with the overload at rendering start… anyone else can observe this?
i hope this problem get fixed by steinberg as soon as possible because i am working on a remix with a deadline at the end of the month 
I’ve not had this issue for a few days now… i’ve updated my gpu driver, iLok and eLC, something i did notice before though was the problem didn’t seem to occur if i exported a couple of bars before any events in the project kick in…
If i tried to export from the start of the project proper, the play cursor would not jump back to the beginning of the project as it does if i left a few blank bars before it…
Might be worth people trying this if they haven’t already…
short update:
cubase 8.0.30 is out and solved the problem for me!
It didn’t for me. Exactly the same as always here.
I recently had success on an original 6.07 project that I was exporting in 8 Pro. I used the maximum buffer size for my RME interface, which is 4096. This turned off ASIO-GUARD and the export worked. So, if you have a high buffer interface try that. However, it is strange that a project that is running perfectly fine at a 256 buffer size needs a buffer size 16 times its size to successfully mix down a project.
I had something similar to this:
The short version:
Bad SSD drives!
If you have SSD, no matter what brand/model…check for firmware/driver updates and make sure your rig is optimized for them! (Cache sizes, over-provision area, proper AHCI drivers, OS indexing options, etc)
Persisted on two of my older AMD 2+ and Core Duo platforms with multiple audio devices…both PCI and USB, both ASIO and aggregated WDM drivers:
First I noticed many VSTi plugins that stream samples reporting ‘disk loss’ errors.
Later when I started doing more with audio tracks I ran into occasional problems here as well.
I ran all kinds of tests, on memory, cpu stability, disk drives, latency, etc…and everything passed with flying colors.
Installed on a friend’s PC…even lower specced than mine, and it all worked well.
As a last ditch effort I moved all my streaming files to an old set of raided hard drives and CuBase started running like a top! I didn’t hear anymore issues until I loaded up enough samples in my 8gig rig that the system started hitting the pagefile.
A few more weeks of moving things around (using xcopy and mklink junctions), and I finally NAILED my problem:
It was two SSD drives:
PNY SSD2SC120G5LC709B121-510
PNY SSD2SC240G3LC709B121-460P
Yep: Tried them on four different SATA hosts (both SATA3 and SATA2), new cables, verified power supply, etc…in two different motherboards (One AMD AM2+ and One Intel Core 2). Tried AHCI and IDE drivers. Hunted updates and such from PNY. They simply seem to HATE A/V streaming activity.
Tried with other DAWS, and they didn’t do so well on those either (disk loss errors with the VSTi plugins, and intermittent pops and clicks when streaming straight up audio).
With some further testing, I discovered they introduce system interrupts (sometimes rather noticeable pauses) when hosting OS pagefiles. While they benchmark ok, and pass the latency tests recommended by Steinberg, there’s just something about them that doesn’t get along with streaming or memory swapping.
Until I could get some replacement SSD drives, I fell back to some rather old raided SATA2 raptors and all those nasty disk errors went away. Now I’m running a mix mash of Samsung model SSD drives (830 and 840) for the OS, pagefile, and any streaming VSTi content, and things work really well. The big audio files get scattered across whatever platter drives I can get my hands on.
Note: With the Samsung drives, I have them and the system optimized as recommended by the included SSD Magic software that came with them. There are quite a few options on setting up those drives, and since I’ve owned them at least three firmware and driver updates have been pushed through. In contrast, the PNY drives did NOT come with any OS/drive optimization software, and I haven’t seen a single firmware or driver update on them in well over a year.
With 8.0.20, I could still see alot of spiky looking activity in the performance monitor, but it didn’t effect the sound and workflow so I simply ignored it, and true OS CPU monitors never topped 20% (running about 40 tracks of VSTi plugins [Mostly Halion 5 and ARIA/sforzando/bidule), plus 8 to 12 audio tracks with about half a dozen VST effects. Now, with 8.0.30, the spiking activity seems to have gone away.
For what it’s worth…
Grab a different hard drive (even if it’s an old SATA2 platter laying around in your closet), pull out all the SSD units, and see what happens with a fresh install with everything running from that. Wish I’d tried that, as it would have saved me many hours of moving stuff around to discover my ‘bad drives’.
Ok just had this issue again… BUT i was trying to export from the very start of the first event in the project… set the left marker two beats earlier than before and BINGO!!!
Seems i’ve found the answer for my own particular issue… if you haven’t tried it already give it a go!
Thanks for your informative post Brian.
However, in my case Pro Tools 11 never has trouble with mixdown, while Cubase 8 Pro does. So, unless Pro Tools and my SSD’s interact differently than Cubase 8 Pro’s and my SSD’s, I don’t see how my SSD’s are the issue. If you can explain otherwise, I’d appreciate it!
Nice one! This is working for me too. 
I had to pull it back about 4 bars though.
Superb!
Glad it worked for you too!
I honestly don’t know if that’s your issue, and I have no clue where ‘fault’ lay. I’m responding because I did see some of the error messages reported in this thread with the PNY drives.
In my case, getting all streaming files and system page-files off the PNY drives fixed things…and it took me a while to track it down. I was so in denial about the drives being my issue, that I even purchased other host controllers to try them on, and revived a stashed away Core Duo rig to run tests, etc. (I needed the extra hosts anyway). My Samsung 830 and 840 model drives work great. In hindsight, I wish I’d tried a different/fresh hard drive right away before I tried some of the more involved trouble shooting steps that I put myself through.
For others, it could be something else. Maybe a sound card…maybe a video card. It can be really frustrating to track it down.
I’ve learned a bit more about how to trouble shoot these sorts of things now (what logs to look for, how to open them and interpret them), so that’s good. Oh well, hindsight is 20/20.
One plugin that really tipped me off to my issue was Plogue’s free sforzando sfz player. That particular plugin was ultra sensitive to disk loss errors, and it has a pretty informative log system…both in the UI itself, and the ARIA engine also has a nice app hidden away in its main installation directory that’ll generate quite helpful debug logs.
On my system I did have problems with apps besides CuBase. With Avid’s Sibelius 7.5, and the bad drives, I had to use ASIO buffers in excess of 1meg to able to use VSTi plugins at all! In some apps or plugins, the glitches were less obvious, but in checking all the logs from the different VSTi and DAW systems they were indeed reporting disk loss and overrun errors. Several of my VSTi’s would pop and crackle no matter what I attempted to host them in. Some VSTi plugins (those more reliant on live streaming rather than putting more samples into memory) were far more sensitive to the issue than others.
Just my experience. Found a hardware issue…got rid of it, and now I’m plugging along with no more spikes, way improved audio performance, and 6ms latency and able to manage up to 40 processor intensive VSTi tracks plus 6 to 8 audio tracks on an ancient AMD Phenom II rig before I have to start rendering some of the VSTi tracks down to pure audio.
If you happen to have a spare drive laying around, or are in need of some extra storage anyway, what would it hurt to give it a try?
Same problem here.
Disk overload error when exporting in realtime.
I see many solutions listed in the thread, many apply to hardware I don’t have.
Situation is an export fails with a disk overload error when doing it in realtime but works fine when doing it in not-realtime. This seems illogical given the non-realtime export presumably is more intensive than the realtime export.
Has the issue been formally raised with Steinberg? Other than exporting from the beginning of the project, has anyone got a Cubase-specific method for dealing with this please?
i7 3Ghz
12GB RAM
GT 640 gfx
W7 x64
C7.5x64 C8 x64
Lynx ASIO
Hello,
I don’t know regarding your HDD?
Cheers
Had this error last weekend too, could fortunately do an offline export, which worked. Have not tried moving startpoint back a couple of bars though…
Hope this gets addressed sometimes.
make sure chrome is closed in the background.
usually it isn’t cubase that is the issue with real-times, it’s something being a processor hog in the background
Chris - the disks are normal HDDs, 7200 rpm on a hardware RAID 5 setup.
I actually think the disk overload message is not the correct error as the only time I get this error is when I am using MIDI and sometimes, it triggers exactly when a MIDI part starts. Additionally, if I do the export in non-realtime, the MIDI doesn’t play back properly which is why I have to do it in realtime.
So my hunch with a bit of evidence comparing various projects in realtime export is that the real cause of the error is something in the MIDI processing.