Sketchup is crashing, trying to print to PDF?


I have a serious problem, when I’m trying to print to pdf, (I’m drawing shop design/layout and need layout in example scale 1:50) Sketchup is always crashing, can someone please help me?

My setup:
Sketch up 2015 pro.
Vray 2,0
Workstation HP Z420:
Xeon E5-1620 3, 7 GHZ
16 Gb RAM
Nvidia Quadro K2000

Best Regards!

Per Folmann

via “File > Export > 2D Graphic > PDF” or by printing via a PDF printer driver?

try if disabling “Window > Preferences > OpenGL > Use Hardware Acceleration” fixes the problem, if yes the driver of your video adapter doesn’t fully support OpenGL.

1 Like

Im printing via a PDF printer driver.

Thank you so much!

That helps me a lot, I’m so happy 6 weeks of frustration is over.

Best Regards,

Per :smile:

1 Like

if you wanna use the display output accelereated by the GPU of the video card, you may want try to update the driver of your nVidia Quadro K2000 or - if this doesn’t help - buy a decent video card as e.g. a nVidia GeForce GTX 960 (or better).

I would like to bump this topic up as I think it is still a serious issue.

I am also experiencing frequent crashes when printing (to PDF printers). Same with different PDF printers.

I have no 100% reproducible situation but it seems to be worse with scenes that contain a lot of leader text or dimensions.

This is on Win7, with SketchUp 2015 Pro 32-Bit. Same problem on two different laptops with reasonable (on-board) graphics chips.

Updating the graphics drivers on both machines to the very latest seems to have helped slightly but definitely not resolved the issue. Trying out the various hardware acceleration settings has not made a difference.

I have committed various crash dumps via bug splat, but not received a response on those from the SketchUp team.

I would be interested to know which crashes have been identified and possibly resolved by the team so far.

All this was not an issue with previous versions (SU7 before).

What happens when you print directly to paper?
Can you export images and PDF/EPS files? 2D DWG?
I also wonder if fonts might be an issue here. Are you using some “exotic” fonts? A corrupt font file can create unexpected problems across your whole system.


For my workflow I am really after exported/rendered PNGs which is why 2D DWG or (hidden line) PDF export wouldn’t help me.

SketchUp’s own PNG export function does generally work (and has not crashed so far), but it does not provide the same control over output scale as the print dialog (the PNG export dialog does not have ‘scale’ or DPI settings, i.e. you cannot relate from model units to print units). Which is why I generate PNGs by printing to PDF printers such as Bullzip or PDF Creator.

I will check if printing to actual paper makes a difference in the crashing situations.

Also thanks for the idea about fonts. Mostly I use Tahoma which I do not expect to be causing problems. But I will check for any more exotic fonts.

disabling “Window > Preferences > OpenGL > Use Hardware Acceleration” should fix all video card resp. video driver related problems, besides maybe if you are using big paper sizes in connection with high resolutions… which generates obvoiusly lots of raster data which may just blow up the data handling of SU and/or the used PDF driver.

The crashes I am seeing definitely occur with hardware acceleration OFF as well.

I have just sent in two fresh bug splats for crashes while printing without hardware acceleration.

Yes, I freely admit that some of my scenes are pushing the limits in terms of geometry, textures, and lots of text and dimensions, as well as print resolution.

I am printing A3 as ‘High Definition’ resulting in images of 4963x3508 pixels. As noted above, same with different PDF printers (and printer settings) and on different computers, so I would not expect the problem to lie there.

Although I need to say that the process generally works very well with good results, and if memory management is pushed to the limits I would love SketchUp to fail gracefully and just not crash.

I do find that sometimes after having crashed on a scene with lots of text repeatedly, I can print a scene without any text but still lots of geometry without problems - which does point in the text/font rendering direction.

Although none of this is 100% meaning sometimes scenes with lots of text go through fine, and sometimes even very lightweight scenes with little geometry or text do crash - some sort of initialization issue perhaps.

could imagine that some sort of buffer resp. memory range which is used during the print output runs tight sothat printing even of big models works if SU is launched freshly and gets in trouble if several print outs were done already.

For evaluating this you may want exit and launch SU every time before printing… just guessing.

btw, which Windows version (x32/x64) and SU version (x32/x64)?

I am running SketchUp 2015 Pro 32-bit - one on Win7 32-bit and one on Win7 64-bit (both same behavior).

Printing from a freshly started SketchUp does not guarantee a successful print - it is more of a random crash pattern - and seems more dependent on content of a scene than number of prints.

But I did notice that sometimes after printing a few on-screen textures (mostly text elements) show rubbish graphics. This usually fixes itself after swapping scenes. But yes, it would point to some buffer over-running or texture pointer mismatch during rendering.

Again, I understand rendering a lot of text to texture in memory might be asking a lot of the graphics card, but surely we can make it not crash. Graphics drivers on both my cards are updated to latest.

Wondering if the SketchUp development team can weigh in on this?

Tahoma has long been used a standard Windows UI font, until Segoe UI replaced it in Vista and higher. (But legacy applications may still specifically load it.)

Read up on “Locked Font Metrics” and you may wish to avoid all of them (fonts with locked metrics.)
MSDN: Fonts and text metrics

could imagine that SUP 2015 x64 may address issues allocating large memory areas in connection with 64-bit printer drivers.

Read up on “Locked Font Metrics” and you may wish to avoid all of them (fonts with locked metrics.)

So I have started testing this with non-Microsoft, non-UI fonts but I am still getting the same crashes.

Crashes while printing whenever there is a certain amount of leader text or dimensions (I have tried either while excluding the other) combined with a certain amount of geometry in the scene.

Incidentally, does anybody have recommendations for ‘safe’ fonts to use in CAD? Preferably ones that still give good presentation. I have tried ‘Simplex’ among others (also crashes).

I have back-converted several critical scenes to SketchUp 7 (!) - which can still print without crashing.

Make sure to send in each BugSplat report. The squeaky wheel gets the grease.

I doubt that fonts are involved, did you have tried with SU 2015 x64?

I have tried SU 2015 64-bit today - generally the same problematic behavior.

But just now I am following another track. I have various automation processes running in the background - maybe it is an issue of applications stealing the focus away from SketchUp in the middle of rendering the print job. Or something along those lines.

you may want use the Windows Resource Monitor, the Windows Performance Monitor and the Windows Event Viewer for doing this.

Can you post at least the header of the bug splat log, i.e. without hex code stuff.

For ensuring that the nVidia video driver of the Quadro does not have any influence on raster image processing even with hardware acceleration (= OpenGL) disabled, you could uninstall and use the native Windows driver instead.

Thanks for the suggestions. I will go for more in-depth investigation when I find the time. For now I need to weave the bug-tracking in with actual production work. Will dig out those crash headers.

The issue is definitely performance-related. I noted the following:

  • The 64-bit system with 64-bit SketchUp (and a slightly newer graphics card) crashes less likely than the 32-bit system.
  • When printing several scenes in succession, the speed at which I run through the print dialog matters. Basically, pressing ‘Enter’ on the print dialog immediately makes a crash more likely than waiting two seconds before proceeding. I use AutoHotkey to automate some tasks and twiddling with timing and delay reduces crash likelihood.
  • It is still definitely Text/Font-related. Scenes without any dimensions or leader text don’t crash.
  • None of the above yields a 100% rule. It is more a combination of factors and likelihood.

Dan: I have sent in well over 20 bug splats with details by now but never heard back. I reckon I still need to go through the official email contact chain to Trimble.

I have never heard directly back either, (that I can remember,) and never really expected to. Can you imagine the waste of time (and money) if a live person had to acknowledge and respond to every crash report ?

I’d rather they just fix the issue(s).