Ongoing Problems With Cannot Parse RTF File Errors

I just downloaded and installed Scrivener 1.0.3. for Windows. When I opened the interactive tutorial, I got the “Cannot parse RTF file” error. I am using Windows XP Professional (5.1, Build 2600) Service Pack 3 (2600.xpsp_sp3_gdr.101209-1647).

I get the parsing error even when I start a new project and reopen it. I have searched this forum and have tried all of the recommended solutions, to no avail. I also see that others have experienced the parsing error in Vista and Windows 7.

This topic hasn’t been updated since mid-November, so I don’t know whether you’ve received sufficient information from users to reproduce the problem. In my own case, when I open the interactive tutorial, as soon as I click on “Beginnings,” I get the parsing error, then a blank page appears. The files are not corrupt, as they display normally in WordPad. Several times, Scrivener has crashed from persistent clicking on the files in the draft folder.

I have done some experimenting and have saved error reporting information from the resulting crashes. The error messages are as follows:

12/2/2011 4:47 AM Application Error Faulting application scrivener.exe, version 1.0.3.0, faulting module scrivener.exe, version 1.0.3.0, fault address 0x00390075.

12/2/2011 5:15 AM Application Error Faulting application scrivener.exe, version 1.0.3.0, faulting module qtgui4.dll, version 4.7.4.0, fault address 0x00179ef2.

Qtgui4.dll belongs to Acronis True Image Home. I also have the companion file to the Windows XP crash report, if it would be of any use to you in tracking down this bug.

I cannot use Scrivener at all until the parsing issue is fixed. As a new user, being subjected to errors which render the software useless upon installation doesn’t give me much confidence in it. I would like to know what the status of this problem is and when we will have a bug fix.

I also have had Scrivener have parsing errors. For me, it usually occurred during a copy and paste process. The problem is very intermittent. I’ll also add, I have tried in vain to force Scrivener to cause parsing errors.

I’m wondering if my computer was interrupted and that wait caused Scrivener to have an error opening/writing to the file. This is just a guess.

I’ll also add when the problem occurs, it causes Scrivener to pause which appears like a possible crash. However, the program doesn’t crash. I really think it gets lost. Also, I haven’t lost any work.

This particular bug is unnerving. I’d hate to lose any work files. I guess the saving grace is Scrivener, by default, saves every 2 seconds, so probably the file has been backed up.

I’m also using XP SP3.

Sorry for the late reply here. Thank you for the reports and the crash info. If there is a project that is consistently throwing this error for you, would it be possible to send a zipped copy of that .scriv folder (along with the specific document number referenced in the error message that’s causing a problem, e.g. “21.rtf”) to support AT literatureandlatte DOT com? We’re having trouble reliably reproducing this, and it seems like there’s more to it than just the specific document since for some people it’s inconsistent.

Could you explain a little more what happened with the error when you were doing the copy/paste? All other reports I’ve seen on this have been either when the project initially loaded or when users were clicking in the binder or otherwise loading individual documents in the editor, so this is new info and I’d appreciate all the details you can give!

As far as the bug itself, the issue is Scrivener being unable to load the RTF file to display in the editor. The text of the file itself is still there in the actual file, so it’s just a load/display issue. I wouldn’t try typing in the file in Scrivener when it’s showing up as blank, but generally speaking just having this error and having the documents not display when viewing the project isn’t harming your work; the underlying files are intact.

For me, the parsing error happened to occur when I was copying and pasting between items in the binder. I have never been able to duplicate the error, so I have to say it’s a coincidence with the copying and pasting. There was another parsing error a week or so ago, but I have no idea what I was doing at the time it occurred.

I installed the trial version on another machine on Saturday. It is an engineering workstation running XP SP2; it had no problems with Scrivener. I have been using my home machine the past few days, and it has had no problems. I think some type of system interrupt is causing the computer to wait for something else to happen. The pause causes Scrivener to lose it’s way for a moment. I agree that no files were damaged. If I remember correctly, I couldn’t do anything in Scrivener when it paused. It did eventually find the file it was looking for and continue. The parsing errors are mostly unnerving not catastrophic for me.

I did purchase a copy of Scrivener even with the parsing errors. I have tried many writing software demos in the past few weeks. In my mind, Scrivener is superior to anything else I tried. The program’s architecture is brilliant. Yes, it has some version 1 hiccups, but I believe I purchased the correct software for me.

Every project I open creates the parsing error. And every single RTF file creates a parsing error. I can send you a zipped copy of a project (.scriv folder), but I believe that the problem is caused by a bug in the software, not an individual project or file. Most RTF parsing problems (I’ve been told) are caused by syntax errors (programming errors), not problems on the computer or with the files themselves.

I say this because I can reproduce the error 100% of the time. The computer I’m running Scrivener on has no other problems. I have installed and tested a lot of software on this computer (including writing and word processing software), and Scrivener is one of only three programs which threw errors right after installation.

I sent an e-mail to tech support, a couple of days ago, with a lot of details about the tests I’ve run to troubleshoot this problem. I am an experienced computer user, and as such, have a lot of troubleshooting software at my disposal.

Among the things I tested were the executable’s dependencies (all were fine), possible conflicts with security software (no conflicts were found), and whether necessary Windows files were missing or corrupt (I ran Windows system file checker).

In my e-mail, I also made suggestions for identifying the problem based on a review of the Scrivener crash reports and information about software installed on my computer. It would be helpful if the developer took a look at some of these reports and/or dump files to pinpoint the problem.

I offered to send you Windows crash logs and dump files, and although I did just receive a reply from tech support (telling me to discuss this problem in the forum), I was not told to send these items to tech support. I also made a screencast showing the parsing problem. You are welcome to have any or all of these things, if you will tell me which items to send.

I have other writing software (which I like and use regularly). But I also have a use for some of Scrivener’s feature. I have not given up on Scrivener yet, but I am disappointed by the the software’s inability to run on my computer.

I’ve passed on all the test information from your email to the developer; thank you very much for sending that. I’m afraid the crash logs aren’t likely to provide much useful information, but if you’ve already got them packed and handy from the WER if you send them I’ll pass those on as well. The screencast would be great–I’ve reproduced this slightly myself but only a once-off, so although I did get some images from that and other people, it’s possible the full video version will show something going on that might trigger ideas for the developer in looking at this. In any case it can’t hurt! Same for the dump files if they’re small enough to send (20MB is the limit for our email server) or if you’d like to upload them somewhere that we can grab them.

I appreciate all the work you’ve done helping to gather info for this bug and your patience as we’re working on this since you seems especially afflicted by it in that nothing will open successfully at all. Lee is working on this, and we’ll put out a release with the fix as soon as we have one.

Just so you know… I sent an e-mail to support last night with the crash logs and dump files as attachments. I also included a URL where you can download the screencast.

Then, I remembered having another utility for troubleshooting executables. This one offers better information for programmers, so I just sent another e-mail to support with the additional log files.

Let me know if anything else would help to fix this problem.

Thanks for the emails; we’ve got them, and Lee’s going through everything. We sincerely appreciate all the help tracking this down!

Hi…I’ve been a beta user since NaNoWriMo 2010 and today finally purchased the ‘final’ Windows software. I am having very similar problems to those of MemeticMouton, though I haven’t seen a blank screen returned. Similar, not not wholly blank.

I had trouble with the install in that the instructions didn’t seem to indicate that I needed to uninstall the former version. After NOT uninstalling for all the previous Beta versions, I was surprised it was required–hence never gave it a thought. I finally Uninstalled it and them the Windows Install was successful. I had downloaded from the link in the invoice.

Well, it was successful EXCEPT for the Parse RTF File errors–and I hesitate to go one inch further until this is cleared up. My installation does open, I did a Save As to get another backup copy, closed the application and then reopened it. The second time, the Parse RTF errors appeared only on opening the app itself (multiple error windows, one after the other) and all were this time related to sections called “Notes” (e.g., Notes_14, Notes_17).

In the initial app open, the RTF error pop-up windows showed when I clicked in a “chapter” in the chapter listing. I’d get the error, say “OK” (though it hardly was!) and then the chapter would appear. Not all the chapters were affected. Perhaps 2/3 were.

The other odd thing I noticed was the way my manuscript was displayed the FIRST (and only the first) time I opened it. Initially, the document (which consists of perhaps 25 variously-named ‘chapters’ in a folder called “DRAFT”) displayed with a page with only the word “DRAFT” in the middle of it–as if the system had picked up the folder title and made it a page.

I don’t have a proper title page at the moment and no page which says only “DRAFT”–anywhere. Something generated that. On subsequent opens, however, that page no longer appeared. The first page which appeared was my “Chapter One” page.

To a non-developer (though I’m married to one so I know what it’s like trying to understand my ramblings because I often see his eyes glaze over when I ‘explain’ something) this simply appears that something got out of order and then, after clicking here and there, it seemed to right itself (mostly).

I have confidence that this is something you’re going to find an explanation for but, at the moment, I’m not going to do anything much in Scrivener until there’s an answer to this. Never mind, I can always write and cut-and-paste in Word. But I’d really like to get going with this ‘final’ version I’ve waited a long time to have!

I really do like it; but I’m ready for the Beta to be over and I’ll bet you all are too!

Rambling and hoping,
cynthia
I am running Windows XP Professional 2002, Service Pack 3 on this machine.

This is normal–it just means you had the Draft folder selected in the binder and the view mode set to single text, which isn’t possible for Draft (it, like Trash and Research, is a special folder and cannot contain text of its own unlike other folders created in Scrivener; it can only have subdocuments). With these settings, you’ll see the name of the folder displayed in the editor.

Meanwhile, back at the ranch…

Update on the Cannot Parse RTF issue:

Thanks to all the data you kindly users have been feeding us, Lee has been able to track the issue so far to a small executable within Scrivener crashing. This file is intended to check all the RTF code before the files load in Scrivener, to ensure that they don’t contain any invalid characters which can cause Scrivener itself to crash, but for some reason (yet to be determined, but Lee is working on this) it’s getting glitchy for some folk and crashing, thus causing Scrivener to not load the RTF files and to display this error.

The workaround for the moment is for you to go into the Scrivener directory wherever you’ve installed it (most likely C:\Program Files\ – it will be (x86) if you’re on a 64-bit system) and rename the file “rtfi.exe” to prevent it from running. This is not an ultimate solution, because without this running it’s possible you may import invalid RTF into Scrivener–it’s easy enough for this to happen when bringing in text from other programs like Word or OpenOffice, which can play a little fast and loose with some of the encoding–and doing so may result in Scrivener locking up and crashing. Since Scrivener does auto-save regularly, you’re not likely to lose a lot of work if this should happen to you, but obviously no one wants their program crashing on them and a crash is a crash so there’s always some risk that you might whatever you’d most recently done if the auto-save hadn’t yet run.

So if you decide to give this a try, please make sure you’re saving your work regularly and be particularly watchful if you’re bringing text into Scrivener (anything typed within Scrivener itself of course will be fine). If you’re only experiencing the Cannot Parse RTF error occasionally, and closing and reopening the project tends to get things running fine, you’re probably better off leaving the file as it is and dealing with the errors if you can bear it; it’s not harming your project in any way, just annoying. I know though that some of you are getting this error constantly and are thus completely unable to do any work, so you might want to give this a try. Keep in mind also that the error itself does not indicate whether your RTF documents are properly encoded or not, so you don’t need to worry that because you’ve seen this your project is automatically at risk for containing invalid characters.

As I said, Lee is still working on this, so hopefully we’ll have a real fix in an update soon. The problem at this point is figuring out what’s causing the rtfi.exe file to crash, but at least progress has been made! One thing that would help would be if you could all let me know where you’ve installed Scrivener on your machine and where your projects are saved (are they the same drive or different partitions?)–this might be affecting the program’s execution. Also, is anyone running on a virtual machine when they experience this error? (It’s ok, you can 'fess up. I do it too. :wink:)

Good news! I found a way to fix the RTF parsing problem. I sent an e-mail to support, approximately 12 hours ago, about my findings. My e-mail reply didn’t record in the help desk thread, so I posted it there as well, just in case Lee didn’t receive it.

I’m reluctant to post my findings on the forum, at this point, because I’d like Lee to review what I found and advise us on how to address this problem.

And for the record… no, I wasn’t using a virtual machine for my tests. I installed Scrivener in several locations on my primary hard drive (on a logical partition, in C:\Program Files\Scrivener, etc.), all to no avail.

I considered every conceivable possibility as to why I was receiving the RTF parsing error – when other Windows users were not – and came up empty-handed. Nonetheless, I persisted in looking for an explanation – and I found one.

After applying my fix, the RTF parsing errors stopped. I can’t help but think that something will cause the errors to return; I’ve opened and closed Scrivener repeatedly, using different projects, and the RTF parsing error has not appeared.

With any luck, we will have this error fixed soon.

I’m experiencing this error consistently on two computers with one project. It occurs immediately as the program is starting. The program is consistently deleting the last scene file I had open. The file name still exists in the Scrivener window, but the file is empty. When I look up the file number cited in the error (in the actual folder), that file number doesn’t exist.

The project is saved to Dropbox. The Dropbox file is on the Desktop of both computers, and on Drive C on both. The path is:
C:Desktop/Dropbox/SCRIVENER NOVELS/[Name of novel]

One computer is a netbook running Windows XP.

The other is a desktop running Windows 7.

This error did not occur when I was running the beta (not the NaNoWrMo version: the version released just after that). The error began IMMEDIATELY after I purchased Scrivener and inserted the registration code. I DID remove and reinstall Scrivener when I purchased it, and then inserted the code, if that matters. The error began the next time I opened Scrivener after the automatic backups began.

Let me know if you want the error logs, and where to find them. Thanks for all your help! I’m about to migrate this entire project to Liquid Story Binder out of sheer frustration and terror but would rather not, so I hope a solution is coming quickly. I prefer Scrivener, but if it keeps killing the scene I’m working on…gah.

Quick update, because I’m theoretically on break right now and my bagel’s getting cold sitting in the toaster untouched…

  1. Liber, thanks for the email, we did get it and I’ve made sure Lee’s aware; everyone’s on holiday now so there may be a delay getting back to you with a follow-up on your findings.

  2. Everyone experiencing this, thanks for hanging in there as we investigate. As mentioned earlier, this isn’t causing corruption to your project at all, it’s simply that Scrivener isn’t loading the files because it believes that there are invalid characters there that may cause the program to crash. There may in fact be invalid RTF code in the projects you’re trying to load, or this may be from the program that’s looking for the invalid code crashing on its own before it can verify the quality of the code.

  3. It would be lovely if those of you experiencing this could ensure that you are completely up to date with all Microsoft updates and security patches, as a few recent releases from MS may affect system libraries that are involved in dealing with some of the code involved here.

Thanks all and happy holidays! I’m off to eat a bagel in celebration. :slight_smile:

As for the Microsoft updates and security patches, do not trust Microsoft to download all of the critical updates to your computer. On my computer, automatic updates is set to install updates after checking with me. Each time there is an update, I review what is being installed for troubleshooting purposes. I install everything Microsoft notifies me of.

When I recently had an update fail, I visited Microsoft’s site to install the updates again. While I was there, I discovered a security patch, which was supposed to be included in the automatic updates, but which had never been downloaded to my computer. It was the only item listed in the update center which I hadn’t installed, since I had already installed everything recommended, including the optional software patches – and there were no hidden updates.

At first, I thought that the initial installation had failed. But, I couldn’t find that particular update in the update history.

I cannot figure out why this update was never installed, and more importantly, why it wasn’t listed in the Microsoft update center the last time I visited.

If you are having problems with the RTF parsing error (or any other bug), do a manual check for the latest Windows updates and look through everything listed under your OS, even optional software updates.

This may actually be a problem with Dropbox–as much as I love and use Dropbox, it isn’t the best place to do your live work (backing up to Dropbox is good, of course). The problem is in how it determines which files are newer/updated vs the online stored ones, and what Scrivener thinks is the latest version of the many little files that make up a project.

This thread at Seeing Dropbox right... has much more information on it.

Hope this helps!

I too have been consistently encountering this error, just trying to load the interactive tutorial (I just downloaded Scrivener for the first time). I have run Windows Update and uninstalled and reinstalled Scrivener to no effect. Renaming the rtfi.exe file did allow me to continue. The file it chokes on from the start is 36.rtf, but I’ve also seen it later choke on 10.rtf and 4.rtf before finally crashing.

For reference, this is running on a laptop running Windows 7 Home Premium (Service Pack 1, fully patched). The hardware is a Dell Inspiron 1545, Pentium Dual Core T4300@ 2.1GHz, 4 GB of memory, 64 bit OS. Microsoft Security Essentials gives a clean report (and has been on continuously). If there are any other details that would help, please feel free to contact me directly: art@artsmithphotography.com

I’m getting the parse error no matter which of my windows 7 computers I try to drag in a .docx or .doc file. It crashes every time.

After using 1.0.3 without problems since install, it’s now, occasionally, throwing up the ‘cannot parse rtf’ problem. Try as I might I can’t find a systematic way to cause the glitch, neither does it do it with the same files repeatedly. :confused:

It’s veeery annoying, but as it doesn’t seem to damage anything It’s liveable with.

Happy New Year to you all, btw. :smiley:

Is there any update on this parsing problem being solved, or if the workaround renaming of rtfi.exe should be used until the next update of Scrivener?

I’ve had to go back to using Liquid Story Binder rather than Scrivener because of this, and … gah, but I miss Scrivener.

The workaround for the moment is for you to go into the Scrivener directory wherever you’ve installed it (most likely C:\Program Files\ – it will be (x86) if you’re on a 64-bit system) and rename the file “rtfi.exe” to prevent it from running. This is not an ultimate solution, because without this running it’s possible you may import invalid RTF into Scrivener–it’s easy enough for this to happen when bringing in text from other programs like Word or OpenOffice, which can play a little fast and loose with some of the encoding–and doing so may result in Scrivener locking up and crashing. Since Scrivener does auto-save regularly, you’re not likely to lose a lot of work if this should happen to you, but obviously no one wants their program crashing on them and a crash is a crash so there’s always some risk that you might whatever you’d most recently done if the auto-save hadn’t yet run.

I’ve just experienced this error after attempting to add text to a project. The file affected was not one I was adding text to however. It seems to occur while Scrivener was attempting to open an installer for another application. After this error the text file appeared blank even though it had contained text previously. If I hadn’t seen that RTF parse error message I would have assumed that the project had become corrupted as the behaviour was the same as a corrupted scrivx file. Could there be some connection?

I managed to fix the problem by reverting the project to the backup I saved yesterday.