Dealing with crashes in Premiere Pro

Dealing with crashes in Premiere Pro


With over a decades worth of editing experience working across a variety of NLEs, you eventually start to preempt the crashes. You tend to encounter most bugs that can be thrown up and you learn how to conquer them. Still however, on certain occasions you encounter issues that not even the senior bods at Adobe can’t fix. I thought I’d write this blog just to share some of the common errors that you may come across in Premiere Pro and where to start trouble shooting.

First up, general playback and “Premiere Pro has unexpectedly crashed” errors. Usually if you encounter this error regularly, there’s something underpinning it. It may be a dodgy codec, plugin or piece of hardware.


A little tip that I learnt from my friend and fellow filmmaker Zoe Davis, is to set the sequence codec. As standard Adobe sets as default to I-frame only MPEG. Whilst this is only for previewing renders whilst you’re editing, I’ve found this to be the root cause of many crashes. To adjust this, go to Sequence>Sequence Settings and it’s the Preview File Format dropdown. I’d suggest setting the sequence codec to Pro Res LT (if your work is primarily for web), Pro Res 422 (for standard broadcast) or Pro Res 444 if you’re undertaking colour critical work. I’ve found this to be the number one fix for many temperamental systems.


Often this will be an issue you hit on whilst starting-up Premiere Pro or whilst rendering a file. It’s one of the first things Adobe will look at if you get in contact with them… Well it’s probably someone else’s fault, not ours! It’s still worth checking though.

Simply create a new folder on your desktop and navigate to

/Library/Application Support/Adobe/Common/Plug-Ins/

Copy the contents of this folder to that of the one on the desktop and then delete everything from the plug-in folder. Restart Premiere Pro and see how it runs. If you encounter no errors, it’s possibly this is what’s causing you the problems. To work out the offending plug-in, gradually reintroduce the plug-ins until you hit the point the crashes start happening. You can then pick up with the developer the issue. It’s important to ensure that the plug-ins you run, are compatible with your system. If you’re running Premiere Pro CS6 and trying run the latest Magic Bullet Looks Suite, well that might just be your problem.


GPU support on various machines has been somewhat temperamental in the past. In recent versions of Premiere Pro, I’ve found the Mercury Engine to be vastly improved and on the latest Macs, run smoothly (99% of the time). This is always worth bearing in mind though if you are encountering crashes. Another sign that this maybe an issue, is if you are encountering random green screens where your video should be or corruption in the picture. Sometimes this might actually physically be the GPU is damaged or not fully supported and apart from disabling it, there isn’t much that can be done without replacing your entire machine.

The first thing to do is to go to File>Project Settings>General. Set the Renderer to Mercury Playback Software Only. Then go to Sequence>Sequence Settings and uncheck the Composite in Linear Color checkbox.

It’s also worth disabling any additional video output you have from Premiere Pro. This is done by going to Premiere Pro CC>Preferences>Playback and unchecking the Enable Mercury Transmit option.


There are several issues to do with Audio outputs which in all honesty I’ve not gotten to the bottom of yet. The Adobe Engineers have a better understand of this but I posted a message on the Adobe Communities site a while back to no avail. I have found that as part of the diagnosis process, I will go through and change the audio outputs under Preferences>Audio Hardware. To see if by doing this I can regain any functionality. Sometimes this works.

Another trick can be to increase the I/O Buffer Size to increase the available buffer. As default this is 512 but I tend to find 1024 or 2048 samples runs smoother. You’ll usually notice this is the issue if the audio struggles to keep up with the playhead and you encounter pops and clicks over the top of your audio.


Next up, consider the file format you’re working in. If you’re putting considerable strain on your machine, i.e. running multiple streams of raw R3D footage, it could be that your system can’t deal with it. I’d recommend knocking the resolution in the Program Window down to 1/4 or transcoding to proxies if it still struggles. I always run atMonitor on my system so I can constantly see what is going on at any point.

Lumetri Scopes

If during playback, your system slows right down and struggles to keep up and it’s not the clip resolution, there’s a possibility the Lumetri Scopes are slowing things down. As default they follow the playhead in realtime and it does pull considerable CPU (and possibly GPU) resources. Whilst it’s interesting to watch the scopes in realtime, it’s not always particularly useful unless you’re grading. I’d recommend keeping the Lumetri Scopes closed when you don’t need them.


Lastly I wanted to get onto the issue of corruption in Premiere Pro projects. This is a hugely irritating and difficult to diagnose issue. I first encountered this issue two years ago whilst working on a multi-camera project I’d synced with PluralEyes (it turns out that Canon C300 cameras aren’t particularly good at keeping timecode…). At the time I found the project would gradually just stop working. It was really bizarre, as if it was getting ill and gradually dying. Playback on a single sequence would stop working and then eventually the entire project would stop. After losing a day or so of work, I manage to find a thread linking Premiere Pro project corruption to Red Giant’s PluralEyes 3, something they refutably deny.

Recently I ran in to a really bizarre issue again with a similar outcome. I’d upgraded to the latest PluralEyes 3.5 and kept up with latest updates but not really used it since the last mass corruption. Having got partway through a project, playback ceased to work in a particular sequence. This then spread to the entire project. I ran through my usual diagnosis steps detailed above but with no luck. After that I opened up a previous project I’d been working on and weirdly nothing would playback. Running through the logic in my head, the only conclusion I could come to, was that my new maxed out iMac 5K was royally f*cked. Not good for someone who makes a living out of using it.

What followed were two entire days of diagnosis with Adobe. One of the first things that the engineers would ask was, are you using PluralEyes on your system? Just to point out once again, Red Giant are still denying there is an issue with PluralEyes… I’d reply to the engineer with “Yes, but this isn’t about one project, this is all projects to which the majority of them don’t use PluralEyes”. 

In total I had 4 remote viewing session with Adobe with them going over my system step-by-step. Eventually this culminated in a 2 hour long phone call with a Senior Engineer. The final point of action the engineer said I could do was reinstall my entire system from scratch and see if the issue persisted. Whilst on the phone to him, I’d been doing my own tests. I found that opening the corrupted project on my laptop, would prevent other projects playing back on that machine. So in my mind, either the project was infected with a virus or corrupted. If it was corrupted, maybe it was corrupting the project media database or cache. I put this to him. His exact words were: “I’m not saying it’s not feasible, but I’m 99% sure this is not the case”. After terminating the call, I deleted my Media Cache and viola playback returned to my other projects at least. Unfortunately I couldn’t regain playback on the corrupted project file. The only way to recover a corrupted project is to export an XML of each sequence and import into a new project. Annoying but at least I regained use of my machine.

So Red Giant have told me they don’t believe that PluralEyes could cause this and they won’t be investigating the issue further. They’ve asked me to replicate the issue on a clean system before they’ll investigate further. Having lost 2 days work already, I politely declined their offer of doing what their engineers should be doing and instead wrote this blog on troubleshooting. I can’t prove this is purely down to PluralEyes, there is scope for a number of other issues within the system to cause this issue. What is undeniable though, is the fact that I work on at least 1 or 2 new projects each week, and in 3 years of using Premiere Pro I’ve only encountered this issue on the 2 occasions I’ve used PluralEyes. 

<< Go back to the previous page