Scrivener 3.1.1. crashes when I try to compile in epub or mobi.

  1. Every time I try to compile a file in .mobi or .epub formats, scrivener crashes during the compile (the progress bar reaches the very end) without actually creating the file.

2.) A Mac crash report popup window appears. (I have submitted a couple of crash reports to Mac).

  1. Every time I re-open any of the tried .scriv projects, the program prompts a rebuild of the index files and the Scrivener crash report popup window appears. (I have submitted a couple of crash reports to Literature and Latte as well).

I have tried removing old preferences, creating new pre-sets, and even re-installing Scrivener. Compiling in PDF format works fine but not .mobi or epub. I have tried to compile with 5 different .scriv projects. The last successful compile of .epub and .mobi files was done on November 10. I am using version 3.1.1.

Similar problem for me with epub, although every once in a while mine will compile. I haven’t been able to pinpoint anything I’ve done ahead of a successful compile that’s different than for an unsuccessful one. I haven’t used mobi, so cannot say about that. I’ve submitted my crash reports, as well.

After many, many trials with numerous manuscripts all day yesterday and today, I discovered that I can compile to the Scrivener Format: Ebooks but not formats I had myself created under My Formats or Project Formats, existing or duplicated. For example, when I duplicate one of my formats and modify it, compiling causes Scrivener to crash without creating the file and without saving on close as I have set preferences to do.

I had previously exported my formats, and as they have worked historically (ever since Scrivener 3 first came out), I know the formats are not corrupt. So, I then tried deleting each format from the compile dashboard, re-importing it, and compiling. Scrivener still crashes on compile of .epub or .mobi.

To have to redo each of my formats for each manuscript would be a nightmare.

I am having the same problem.

I have gone back to using version 3.0.3 until this bug is fixed.

Please check to see if you are using a layout with the “Section Break (folders only)” setting. Someone I helped in our support queue traced the problem to layouts with that specific setting.

The same user also reported that exporting the format from 3.0.3, then importing into 3.1.1 fixed the problem.


Could you please attach a sample project (zipped up) that shows the problem? I think I have this fixed for 3.1.2, but I would like to ensure it is the same issue.
Thanks and all the best,
Keith (326 KB)

Is it possible to run both 3.0.3 and 3.1.1 without messing anything up? I reverted to 3.0.3 in order to be able to compile using my own formats but would like to continue to investigate the issue with 3.1.1.

I had reverted to 3.0.3. for a while, just to be able to compile. I reinstalled 3.1.1. and removed all of the “Section Break (folders only)” settings from my format, but this is still happening.

112119-crash-at-911pm.txt (223 KB)

Wondering if there is an update on this?

I’m experiencing the same crashes as reported above. I have files created and compiled successfully in the previous version of Scrivener that crash with 3.1.1. in both mobi and epub.

I am able to compile them in pdf.

I am reluctant to replace the current version with 3.0.3.

I downloaded Ellis’ sample file above and was able to compile it both in the default ebook format and in my own variation. That makes me wonder if there are more than one trigger for this crash.

Above, Keith mentioned a possible fix in the next release. Please let us know how this is coming and when the next update will be coming out.


Same issue here, I had to downgrade to 3.0.3 on Mac to get it through. Please let us know when fix is in. Thanks!

Having the same issue.

I ran into this this week. In my case, I narrowed it down. I had the first line of a chapter as 'November Fourth’. I had a ‘flush left’ paragraph style for that line, and I had selected just those two words and added an Emphasis character style.

This combination is what caused a compile crash. After 3 hours of trying to narrow down where the problem was, I discovered that if instead of selecting just those two words to put the Emphasis style on, that if I selected the entire line (paragraph) by double-clicking, and then put the Emphasis style on that entire paragraph (which was just those two words) the problem went away.

If you add the little tinted box to the Emphasis character style (redefine the style and add that) it is easy to see the difference in the editor. It looks the same in compile, but this way you can see whether the entire paragraph is selected in that style or just the words.

Interestingly, selecting just one word or two inside a line of text and applying the Emphasis style does not crash the compiler at all, only if there are only words with Emphasis and the entire paragraph does not have the style added.

I reported this to Keith, and he is hard at work fixing it.

So, this might be the sort of issue you are having, if not the exact issue. Try compiling just one chapter, or just one text doc, or other methods. If you find that some things crash and some don’t, there’s your clue, and eventually you can narrow the problem down. Then report it to Keith, and he will address it.

Wow, thanks, Jack. If I understand you correctly, compiling chapter by chapter or text doc by text doc and then making sure the style is correct on the doc when I run into a crash would take more time I have, as this problem occurs with all of my manuscripts, an issue that does not ever happen with 3.0.3.

As I cannot compile anything with 3.1.1. I have reverted to 3.0.3. (I don’t know if I can install and run both 3.0.3 and 3.1.1. simultaneously on my computer—I’m afraid it will mess up my files anyway) and so, I cannot troubleshoot further without installing and reinstalling every time (which also makes me fear program corruption, I have done this 5-6 times already).

And thanks, Steve, I’m watching this thread closely. I would love to be able to use the new features of 3.1.1.

The main point here is to figure out where the actual problem is by selectively compiling. That’s the key, because you will have to figure that out and change it to fix the problem anyway. But selective compiling can find that needle in your haystack eventually, and once you know what is causing the problem, then you can change it wherever it needs to be changed in your project.

You can’t fix it if you can’t find it first and identify it, so that is the first step. No crash means no corruption, a crash means corruption. This means this method can narrow down exactly where the corruption lies by process of elimination. Then, it can be fixed. Sometimes just retyping a line or a paragraph can be enough to remove the corruption.

Once you have the offending doc corralled, you might see something that sticks out. The way I discovered the Emphasis issue was by removing the style and putting it back in, and inadvertantly putting the entire line in Emphasis instead of the two words. So I stumbled into the fix, rather than was knowing how to fix it. But this sort of tinkering can solve the problem sometimes.

In my case, once I figured out what made it crash, I went through the entire project and changed similar instances, then compiled again. But the reason I could do that is because I identified the problem first. Then I just used ‘Find by Format’ and checked all instances of Emphasis to make sure that a short line such as ‘November fourth’ was configured as an entire line in Emphasis. But the point is that I had to identify where the problem was first to be able to see what the problem was. Once you do that, only then can you fix it.

The quickest way I could find to track this down is to compile with just one chapter, then add a chapter at a time until it crashes. IOW, compile with just ch 1, then with ch 1-2, then with ch 1-3. Or just ch 1, then just ch 2, etc. Once it crashes, you know what chapter the culprit resides in. Then, if you have multiple docs in that chapter, try compiling with just one doc, then two, etc. Once you narrow it down to one doc, make a duplicate of that doc but don’t add it to the compile.

Starting with small amounts (one chapter or one document) and adding then compiling over and over actually is faster than starting with everything and removing chapters one at a time, because every crash implies a relaunch of Scrivener and the crash reporting window comes up. Plus, it takes a while to compile 60 chapters, so start small. Once you get down to a single doc, the fastest way is to remove all paragraphs but one, compile, then add paragraphs cut-and-paste back in from the duplicate doc, one at a time.

Here’s something else to try while we wait for the next update to correct this problem.

As I stated above, although I wasn’t able to use my personal ebook format without crashing the program, I was able to use the Scrivener-supplied default ebook format. So, because I have to get advance review copies out now, I cloned the default template and modified it to resemble my personal format, in effect replicating the process I took to create my personal template in the first place. Along the way, I did numerous compile tests. None of them crashed. So I’m pretty much back to where I was before the last update with a template that works the way I want it to.

I suspect there are various things that can trigger a crash when compiling to ebook, but give the default template a try. You may be able to get back to work before the next update.

I’m on a mac, running 3.1.1 and not able to compile epub or mobi. Prior to November I never had a problem. I get as far as the blue progress bar filling, the beach ball rolling, then it just stalls. Is there a fix? Should I delete the software and reinstall?

I’ve tried reinstalling 3.1.1. many times; it doesn’t help. I’ve also spent hours/days troubleshooting. Others have suggested workarounds, but I have too many .scriv projects to go through each one scene by scene, format by format. I suggest reverting to 3.0.3 until the issue is resolved with the next release (hopefully).

Thanks for the reply. Glad I asked. I don’t know how to revert back but I’ll look into doing that. I saw the workarounds, I’m with you. Just not an option. I had big plans this past week and this has been the hair in my soup.

So I have that same problem. I’ve tried to narrow down the issue through delta-debugging (only exporting parts of the document) but I cannot narrow down the problem. As of now, this is a showstopper issue for me.

Considering how many people seem to have the problem, and considering how long it has been a problem, I am surprised that it is not yet fixed. Export to epub/mobi is certainly one of the main use cases for Scrivener, isn’t it?