Crash in SUModelRelease (heap damaged)

I have an skp file that can be opened without problem in Sketchup Viewer 2020 version 20.0.363.
In my example application it crashes when trying to release memory.
Example code:

std::string filepath_utf8 = get_filepath();
SUModelCreateFromFile(&_model, filepath_utf8.c_str());
SUModelRelease(&_model); //crash here "Critical error detected c0000374" in output window

patio.skp (2.6 MB)
Could you help what can I do?
Thanks in advance,

Something in your patio.skp file is causing Sketchup.exe to crash while trying to close the file. It isn’t your example code that is at fault.

To fix the file, I opened patio.skp in Sketchup, copied all of the model to the clipboard, opened a second Sketchup window and pasted the model into it. Then I saved the copied model to a new file name. Those steps eliminated the problem with the skp file.

Thanks for your explanation. Although can you suggest something to avoid crash in the SDK? I mean not only the SDK faults but the caller application (my) also crashes. No chance to catch with try-catch of __try-except mechanism.


Are you using the latest SDK version ?

The 2018 release saw the C API get the SUModelFixErrors function.

You could try running this function on models … but then what should code do if the result does not fix the problems in the model ?

In reality this crash shouldn’t be happening but some rare corruption somewhere in the patiox.skp is causing a problem for the sketchup core when it’s closing the open document (I think I saw that on a stack trace). I’d just fix the sketchup file, continue with life, and it’ll probably never happen again.

Here are the details of the crash in the SketchupAPI dll. This was just a simple routine that opened and closed the file. Something like this:"

SUModelRef model = SU_INVALID;
SUResult res = SUModelCreateFromFile(&model, innie);
if (res != SU_ERROR_NONE) return 1;
SUModelSaveToFileWithVersion(model, outie, version);

SketchupAPI.dll 20.0.363.0

           dwFirstChance: 1
           ExceptionCode: C0000005 (EXCEPTION_ACCESS_VIOLATION)
          ExceptionFlags: 00000000
        ExceptionAddress: 000007FEE44D6F15 sketchupapi.000007FEE44D6F15
        NumberParameters: 2
ExceptionInformation[00]: 0000000000000000 Read
ExceptionInformation[01]: FFFFFFFFFFFFFFFF Inaccessible Address
First chance exception on 000007FEE44D6F15 (C0000005, EXCEPTION_ACCESS_VIOLATION)!

The error is raised here!
000007FEE44D6F15 | FF50 08                  call qword ptr ds:[rax+8]           

RBX : 0000000000000000
RCX : 0000000000442D10
RDX : 0000000000000001
RBP : 000000000043D860
RSP : 000000000027F920
RSI : 0000000000000001
RDI : 0000000002DB4430
R8  : 000007FEE482CBA8     sketchupapi.000007FEE482CBA8
R9  : 00000000000000FE     'þ'
R10 : 0000000000100000
R11 : 000000000027F5C8
R12 : 00000000003CF536     "C:\\Users\\swilliams\\Desktop\\patiox.skp"
R13 : 0000000000000000
R14 : 0000000000000000
R15 : 00000000003CF55C
RIP : 000007FEE44D6F15     sketchupapi.000007FEE44D6F15
RFLAGS : 0000000000010202
ZF : 0
OF : 0
CF : 0
PF : 0
SF : 0
TF : 0     L'Ā'
AF : 0
DF : 0
IF : 1
LastError : 00000000 (ERROR_SUCCESS)
LastStatus : 00000000 (STATUS_SUCCESS)
GS : 002B
ES : 002B
CS : 0033
FS : 0053
DS : 002B
SS : 002B

If you want to handle this case, I think this is the correct document.

1 Like

Thanks for your answers DanRathbun and sWilliams. I tried the SUModelFixErrors but it returned SU_ERROR_NONE and the crash did not disappear. I’m using the SDK that can open and write 2020 skp files. Then I tried again SEH as before with __try - __except pairs.but did not help. I found an article that explains SEH is intentionally not catching heap corruptions. But it does not matter I will simply explain to our user the problem and hope it happens once in a decade :slight_smile:


I looked around for something simple to use as an example and decided to add the exception handling code to Miss Eneroth’s open-newer-version covertversion.exe. As you’ll see this is pretty straight forward and it works just fine.

Here’s the code

// An example of exception handling with _try and _except
// added to Eneroth's open-newer-version

#include <SketchUpAPI/common.h>
#include <SketchUpAPI/initialize.h>
#include <SketchUpAPI/model/model.h>
#include <unordered_map>
#include <string>// std::string, std::stoi

int copyfile(const char*, const char*, enum SUModelVersion);

// command line: convertversion.exe source target version_number
// - Source path
// - Target path
// - SketchUp version (without leading 20)
int main(int argc, char* argv[]) {
  if (argc != 4) return 1;

  const char* source = argv[1];
  const char* target = argv[2];
  int version_name = std::stoi(argv[3]);

  // REVIEW: Must be a way to simply append number to "SUModelVersion_SU" string
  // and get enum from its string name.
  const std::unordered_map<int, SUModelVersion> versions = {
	// When adding new version here, also update HIGHEST_SUPPORTED_SU_VERSION in open_newer.rb.

  enum SUModelVersion version =;
  int result = copyfile(source, target, version);
  return result;

int copyfile(const char* source, const char* target, enum SUModelVersion version) {
	SUModelRef model = SU_INVALID;
	__try {
		SUResult res = SUModelCreateFromFile(&model, source);
		if (res != SU_ERROR_NONE) return 1;
		SUModelSaveToFileWithVersion(model, target, version);

	// EXCEPTION_EXECUTE_HANDLER will force handling of all exceptions. Probably not what you want.
	// for more informrtion on inplementing the __except 'filter' expression, visit 
	// and

	__except (puts("in filter"), EXCEPTION_EXECUTE_HANDLER) {
		puts("in exception handler");
		return 2; // your error code

	return 0;

1 Like

I logged this in our issue tracker:

1 Like

I can reproduce the crash. It appear to relate to releasing the styles in the model, particularly some sketchy edges style.

On my machine SketchUp crashes when I close the document (File > New). So this isn’t isolated to the SDK. Quite possibly something corrupt in the file itself. Will have to investigate further.

1 Like

I’d be careful by blindly handling any error like this. The application terminates because of an unexpected error - and anything after this point is hard to trust.

1 Like

Thank you.


I can confirm we have customers experiencing the same issue by crashing our product. The patio.skp file in GitHub repros on Windows with a silent crash / exit, but on macOS, our crash / bug collecting and tracking system has received several reports with the same stack trace.