Hello @fss,

thank you for reaching out to us. I would first point out three things:

We cannot help users with bugs caused by third party plugins or libraries. We cannot disclose how to read our crash reports in detail, both from a practical and willingness standpoint. I also have difficulties following what you are here talking about in all detail; it is just a little bit too much tech jargon for my librarian brain. Information about Cinema 4D Crash Reports

The primary data provided by a crash report is the _BugReport.txt file. It contains a stack trace for the list of stack frames which led up to the exception/crash. Our traces are organized bottom-up, i.e., the first entry in the stack is the thing which led to the crash.

Stack traces mostly make sense in an environment where you have also access to the source code (or debug symbols) of the binary you are debugging. You can debug against our SDK, or more specifically the frameworks contained in them, to get more meaningful stack traces when debugging, however:

We cannot provide the full declarations of the Cinema 4D API (i.e., the private frameworks and core modules) or debug symbols for them. When you want to debug a binary that is not port of Cinema 4D, e.g., the Corona plugin binary, you will either need at least the declarations of entities (a.k.a. "frameworks") or the debug symbols for it.

So, when a crash happens in our core, you will also not get too much useful information out of a debugger attached to the binary with the public frameworks included. Because they do not contain information about our core. In its serialized form a trace (a _BugReport.txt) does not provide too much useful information.

// The stack trace container. CINEMA_4D_Crash_Report_WINDOWS { // The thread container in the trace. Call_Stacks { // The thread in which the exception did occur. Call_Stack_Thread_9180 { // The stack frame which caused the exception which led to the crash. Here it happened // in the binary which handles a CPython virtual machine for Cinema 4D. pythonvm.module.xdl64: Ordinal0 + 0x14ae32 (SP: 0x000000BD342F8850, PC: 0x00007FFADC16AE32) // The frame before that in the same binary. pythonvm.module.xdl64: Ordinal0 + 0x145db3 (SP: 0x000000BD342F8950, PC: 0x00007FFADC165DB3) // The call before that came from the CPython binary, it yields a bit more descriptive // information without a debugger attached, as we get here function names and not just some // memory offset to the binary. python39.dll: PyUnicode_InternInPlace + 0x461 (SP: 0x000000BD342F89B0, PC: 0x00007FFAD8221DDD) // ... } // A stack trace for another thread which has been executed. Call_Stack_Thread_BLAHBLAH { // ... } //... } }

I do not really understand where you get your information from regarding logos, 'KernelLand', and the 'hexadress of the position in the dump that corresponds to the error number'. But without the source code or debug symbols you cannot make much sense of it.

It could be that Corona is using a lot of Windows libraries, but in general, our code is very OS agnostic. So, it seems unlikely that you found a crash in a Windows binary.

Cheers,
Ferdinand

Where to report a bug?