Revit Crashes When Creating PDF

[Anonymous]

All of a sudden none of our employees can make PDFs of a job. Revit just crashes when they try. Any ideas of what could be causing this? Revit 2017.2.

[Matt__W]

Sounds like a bit of corruption within the model. You can do a simple check yourself by performing the following steps...

1. Open the model. 
2. Save out the families to a temporary location that can be deleted (you don't want to overwrite any company standard families with potentially corrupt ones). When Revit finds one that's corrupt, it will crash or throw up an error message.
https://knowledge.autodesk.com/support/revit-products/learn-explore/caas/CloudHelp/cloudhelp/2016/EN...
3. Make note of the family that crashed Revit.
4. Close Revit.
5. Reopen Revit.
6. Open the model from step 1.
7. Reload and overwrite the corrupt family from step 3 using a clean copy from a company directory of standards, for example.
8. Save the model.
9. Repeat steps 2-8.
10. Wash-rinse-repeat until Revit doesn't crash while saving the families.

[Anonymous]

No families came up as corrupt.

[Matt__W]

Are there any links in your model? What happens if you UNLOAD them prior to PDFing? Does it help? Just trying to rule out if it's an issue with links or your model.

[m.voss.alvine]

any job or a specific job?  If its happening on 1 particular job, does that job have irregular crop regions on views?

[Anonymous]

One Specific job. Its a huge job, 1GB. I don't think there are any "irregular" cropped regions. I'll have to look at that. A possible issue was that we had this error:

I cleaned that up. Going to have some drafters try and make pdfs again. See if that was the issue.

[f.cornelius]

Have you tried exporting sheets to DWFx and then in designreview plotting to PDF using batchplot?

This has the advantage that you don't have to look for the exact sheetsize, but let DesignReview do that for you.

Usually I work in small batches (10-15 sheets a time, which is mostly a subdiscipline), as Design Review can be a bit stubborn with big batches.

[Anonymous]

I will look into trying that. Problem is that we have 200 sheets. After running through this myself. It looks as if the sheets that are causing the crash do have a plan region on it. Its not "irregular" as a previous person mentioned. Wonder if that is the issue. If so, how to fix it?

[Anonymous]

Here is the message I get when Revit crashes by the way.

[Matt__W]

My first thought would be "video graphics card driver needs updating".

What card and driver version do you have installed??

[Matt__W]

And have you cleaned out your temp files recently??

https://knowledge.autodesk.com/search-result/caas/sfdcarticles/sfdcarticles/How-to-delete-temporary-...

[f.cornelius]

The stanndard Windows error...

Do you have the system specs of the machine you're trying to plot on?

If you monitor the system on the taskmanager before and during plotting; do you see a spike somewhere to full load (100%) on CPU or memory?

It might be that the plot job is too intense for your specs.

[Anonymous]

System Specs:

- There are no spikes when I plot and/or when it crashes.

- I cleaned out the temp files.

[f.cornelius]

What PDF printer do you use to plot PDF's with?

Does it still work for other projects?

I remember having a similar issue with a corrupted project, which in the end proved to be pain in the rear-end. Though that model had problems on top of problems.

Another work-around might be to export to dwg with colors set to RGB. After that you could use publish in AutoCAD and publish to PDF. RGB will overrule the plotstyle table, but this is a lot of work extra. Would only use that if you really need the sheets now. This could give you some extra time to look for the problem.

[Anonymous]

We use Bluebeam for pdf.

So, I removed all the plan regions off of a couple views that we use them for different view ranges in the same view. The set prints now. Ok, well... That is obviously the problem. Any ideas on how to work around this? We need the plan region to show all our devices in the view. 

[Anonymous]

Now I'm straight up confused with this problem. So, I printed a set using the "in-session" print setup. The whole job prints with no problem. Then I switch the setup to our setup for documentation and it crashes. The difference I see is the  "SIZE" and the "COLORS". What the heck is going on? I'm completely confused now.

"in-session" setup

Our Documentation Setup:

[f.cornelius]

Okay... Now I'm confused as well.

Logically thinking this would mean that something is up with the printing setup.

Have you tried recreating the printing setup?

Bigger paper size means more pixels means more resources needed. Same goes for color. Though seeing the specs you're running I'd think you shouldn't have any problems with it.

[Anonymous]

Rebuilt the setup. Still crashes. To make this even more confusing. There seems to be one specific sheet that is causing the crash. So, I printed the one sheet by itself and it created the pdf without problem. Then I tried to run a couple of prints before, after and including the issue sheet. It crashes. So, if its in a set of prints it crashes, if its by itself, it creates the pdf. What???

[michael.coviello]

@Anonymous,  Thanks for posting this issue to the forum.

Do you get the same results when you try a different pdf writer?

Can you reproduce and attach a journal file to the thread or send me an IM?

Thank you.

[Anonymous]

We currently do not have another pdf writer.

I attached my journal file. Thanks.