(edit) Cubase 13.0.40 crasht beim Beenden

[NorthernDecay]

Hallo!

Nach dem beenden von Cubase, kommt nach dem Schließen immer eine Fehlermeldung (Foto) und beim erneuten öffnen, kommt das Fenster "sicherer Modus".

Mit Cubase 12 keine Probleme bei gleichen Projekten und mit Studio One, auch keine Probleme.

VST3 Ordner schon verschoben und alle Optionen vom "sicheren Modus" ausprobiert.

Einstellungsordner ebenfalls verschoben.

Das passiert erst seit der 13.0.40 mit der 13.0.30 war alles ok.

System, PlugIns, Audio- und sonstige Treiber sind alle auf dem neuesten Stand

noch erwähnenswert:

wenn ich an der Audiokonfiguration was ändere, anderer Treiber oder Ausgang beim Controlroom deaktivieren und die normalen Ausgänge wähle, dann kann ich Cubase normal beenden ohne anschließende Fehlermeldung. Das funktioniert aber nur einmal, beim erneuten starten des Projekts und dann wieder schließen, kommt der Fehler wieder.

und noch was:

nach dem Beenden kommt kein Hubfenster mehr, aber ein Popupfenster, das zeigt, das der Mixer/Kanal sich entlädt... danach kommt dann die Fehlermeldung.

Edit: Wichtig!

Ich hatte auf dem Laptop noch die Setup-Datei von Cubase 13.0.30

...darum habe ich Cubase 13.0.40 mit allen Komponenten deinstalliert und die Registry gereinigt

...dann die 13.0.30 installiert.

keine Probleme mehr!

d.h. die Ursache liegt im Update von 13.0.40 und nicht an meinem System, oder da ist jetzt was bei, was nicht zu meinem System passt!?

...hat jemand ähnliche Probleme mit dem Update?

 

[Joost]

Zumindest hast Du ein Speicherabbild, welches man in den Microsoft Debugger WinDBG laden kann, um zumindest ansatzweise aus dem dort dann dargestellten CallStack sehen kann, woran es liegen kann. Ich denke mal, daß Steinberg eine dazu passende Debug Datei von den entsprechenden Cubase DLLs herumliegen hat, um das bis auf Sourcecode Level auflösen zu können.

Fallst Dich das näher interessiert:

Installieren von WinDbg - Windows drivers

Beginnen Sie hier mit einer Übersicht über den Windows-Debugger und die Installation von WinDbg.

learn.microsoft.com

Ich würde Steinberg die .dmp Datei mal in den Supportkanal geben. Die können sicherlich zusammen mit der Information, um welche Versionsnummer es sich handelt, etwas damit anfangen.

 

[NorthernDecay]

Alles schon erledigt Joost, auch ein Ticket bei Steinberg liegt vor, mit allen Daten und Bildern.
...bis jetzt noch keine Rückmeldung
Ich selber kann mit WinDbg nichts Offensichtliches erkennen.

 

[TheTick]

Danke, ich wollte gerade updaten

 

[RefinedRough]

Den Fehler hatte ich soweit ich weiss bei JEDER Cubase-Version ausser 12. Find ich gut, dass sie den jetzt wieder eingebaut haben, ohne Absturz ist's irgendwie kein richtiges Cubase-Gefühl

 

[Gast90407]

Ich nutze - als lupenreiner Amateur - Cubase 13 Pro nahezu täglich, seit Tagen auch die Version 13.0.40. Das Problem tritt hier nicht auf.

 

[Schludi]

Danke, ich wollte gerade updaten

Also bei mir crasht es nicht, hab es gerade installiert.

 

[NorthernDecay]

Den Fehler hatte ich soweit ich weiss bei JEDER Cubase-Version ausser 12. Find ich gut, dass sie den jetzt wieder eingebaut haben, ohne Absturz ist's irgendwie kein richtiges Cubase-Gefühl

…herrlich! Lachen mit und um Cubase, Du rettest mir den Tag

 

[Joost]

Bei mir läuft die Version vom 13. Mai stabil.

Als jemand, der diverse Jahre Erfahungen mit CallStack Analysen gesammelt hat, wurde ich natürlich durch Deine Meldung getriggert.

Ich finde es etwas schade, daß Steinberg keinen automatischen Rückkanal für CrashDump Dateien anbietet, dabei ist das Ganze kein Hexenwerk. Ich war vor Jahren mal mit dem Aufsetzen eines plattformübergreifenden CrashReporters mit anschließender statistischer Auswertung der CallStacks und durch einen Schwellwert angetriggertes automatisches Anlegen von Bugreports an die für den jeweiligen Codebereich zuständigen Entwicklern beteiligt (Das war im Kernentwicklungsteam bei StarOffice/OpenOfffice.org, also auch in Hamburg Hammerbrook ). Somit konnte man recht schnell nach einem neuen Release die wichtigen Bereiche von Crashes herausfinden, priorisieren und per Minorrelease fixen. Das System habe ich damals neben meinen anderen Tätigkeiten betreut. Die Anwendung hat damals, sofern der Benutzer dem zugestimmt hat, entsprechende Daten per Soap Interface an einen Webserver geschickt, welcher die Daten dann durch eine Firewall hindurch, in eine Datenbank abgelegt hat. Dann durch eine weitere Firewall hindurch wurden diese statistisch ausgewertet und Bugs im OpenOffice.org Bugtracking System erstellt und den Entwicklern zugewiesen. Und das mit damals etwa 120 Mio. Benutzern weltweit.

Bei Windows Anwendungen, die per MS Visual C++ Compiler gebaut wurden gibt es eigentlich nur den Weg, über dmp Dateien + Memory Mapping Tabelle
Bei Unixoiden (also auch MacOS) gibt es Kernelaufrufe, um direkt einen CallStack der Anwendung zu generieren. Dabei ist es eigentlich egal, welchen C++ Compiler man verwendet.
Selbst bei Java Anwendungen kann man einen CallStack generieren (jstack)
Wenn man bei C++ Anwendungen den Debug Build eines Release Builds behält (das kostet natürlich Plattenplatz) kann man damit bis auf Zeilenebene im Sourcecode zurückverfolgen, wo der Programmabsturz geschehen ist. Zumndest sollte man die Binärdateien nicht strippen, damit man zumindest die Objektnamen im CallStack noch nachverfolgen kann

 

[NorthernDecay]

Bei mir läuft die Version vom 13. Mai stabil.

Als jemand, der diverse Jahre Erfahungen mit CallStack Analysen gesammelt hat, wurde ich natürlich durch Deine Meldung getriggert.

Ich finde es etwas schade, daß Steinberg keinen automatischen Rückkanal für CrashDump Dateien anbietet, dabei ist das Ganze kein Hexenwerk. Ich war vor Jahren mal mit dem Aufsetzen eines plattformübergreifenden CrashReporters mit anschließender statistischer Auswertung der CallStacks und durch einen Schwellwert angetriggertes automatisches Anlegen von Bugreports an die für den jeweiligen Codebereich zuständigen Entwicklern beteiligt (Das war im Kernentwicklungsteam bei StarOffice/OpenOfffice.org, also auch in Hamburg Hammerbrook ). Somit konnte man recht schnell nach einem neuen Release die wichtigen Bereiche von Crashes herausfinden, priorisieren und per Minorrelease fixen. Das System habe ich damals neben meinen anderen Tätigkeiten betreut. Die Anwendung hat damals, sofern der Benutzer dem zugestimmt hat, entsprechende Daten per Soap Interface an einen Webserver geschickt, welcher die Daten dann durch eine Firewall hindurch, in eine Datenbank abgelegt hat. Dann durch eine weitere Firewall hindurch wurden diese statistisch ausgewertet und Bugs im OpenOffice.org Bugtracking System erstellt und den Entwicklern zugewiesen. Und das mit damals etwa 120 Mio. Benutzern weltweit.

Bei Windows Anwendungen, die per MS Visual C++ Compiler gebaut wurden gibt es eigentlich nur den Weg, über dmp Dateien + Memory Mapping Tabelle
Bei Unixoiden (also auch MacOS) gibt es Kernelaufrufe, um direkt einen CallStack der Anwendung zu generieren. Dabei ist es eigentlich egal, welchen C++ Compiler man verwendet.
Selbst bei Java Anwendungen kann man einen CallStack generieren (jstack)
Wenn man bei C++ Anwendungen den Debug Build eines Release Builds behält (das kostet natürlich Plattenplatz) kann man damit bis auf Zeilenebene im Sourcecode zurückverfolgen, wo der Programmabsturz geschehen ist. Zumndest sollte man die Binärdateien nicht strippen, damit man zumindest die Objektnamen im CallStack noch nachverfolgen kann

…ich verstehe nicht mal die Hälfte von dem was Du da schreibst …eigentlich wollte ich nur Musik machen und dafür ist Cubase schon kompliziert genug

 

[Joost]

…ich verstehe nicht mal die Hälfte von dem was Du da schreibst …eigentlich wollte ich nur Musik machen und dafür ist Cubase schon kompliziert genug

Du hast ja Recht....
Da dies aber ein Cubase Thread ist, dachte ich mir, daß hier sicherlich auch mal ein Steinberg Mitarbeiter mitliest, welcher die Hintergrundinformation versteht und zu schätzen weiß...

 

[Whitenoisestudios]

Also bei mir crashen sowohl 13.0.30 als auch 13.0.40 bereits beim Start bevor man überhaupt ein Projekt öffnen kann mit "Kernelbase32.dll" Error.

Egal ob man mit externen Plugins oder alternativem Audiotreiber(auch den Steinberg ASIO) startet.

Die 13.0.20/21 Version hatte das Phänomen nicht.

Ich nutze wohl ein eher seltenes Hardware-Setup mit einen Dual Xeon Mainboard und zwei Xeon CPUs.

Der Fehler liegt eindeutig reproduzierbar an Hyperthreadingeinstellung. Stellt man Hyperthreading im Bios aus, kommt es nicht zu dem oben genannten Fehler und Absturz.

Die Auswertung mittels WinDbg der *.dmp Datei des Absturzes war aber in meinem Fall seitens des Troubleshooting nicht besonders hilfreich/zielführend.

Ich habe mich noch gewundert, denn Kernelbase32.dll impliziert ja irgendwie auch 32Bit.

Ich stecke aber zu wenig in den programmiertechnischen Details von Windows, als das ich das wirklich beurteilen kann, ist nur eine Vermutung.

In meinem Fall handelt sich um Windows 11 Workstation, also ein 64 Bit Betriebssystem.

 

[Joost]

Also bei mir crashen sowohl 13.0.30 als auch 13.0.40 bereits beim Start bevor man überhaupt ein Projekt öffnen kann mit "Kernelbase32.dll" Error.

Egal ob man mit externen Plugins oder alternativem Audiotreiber(auch den Steinberg ASIO) startet.

Die 13.0.20/21 Version hatte das Phänomen nicht.

Ich nutze wohl ein eher seltenes Hardware-Setup mit einen Dual Xeon Mainboard und zwei Xeon CPUs.

Der Fehler liegt eindeutig reproduzierbar an Hyperthreadingeinstellung. Stellt man Hyperthreading im Bios aus, kommt es nicht zu dem oben genannten Fehler und Absturz.

Die Auswertung mittels WinDbg der *.dmp Datei des Absturzes war aber in meinem Fall seitens des Troubleshooting nicht besonders hilfreich/zielführend.

Ich habe mich noch gewundert, denn Kernelbase32.dll impliziert ja irgendwie auch 32Bit.

Ich stecke aber zu wenig in den programmiertechnischen Details von Windows, als das ich das wirklich beurteilen kann, ist nur eine Vermutung.

In meinem Fall handelt sich um Windows 11 Workstation, also ein 64 Bit Betriebssystem.

Das klingt ja echt mies.

Das mit den Hyperthreading Einstellungen hatte ich im Steinberg Forum gesehen, aber das war ein älterer Eintrag

Hab da noch nen Artikel gefunden (auch ein wenig älter):

https://forums.steinberg.net/t/kernelbase-dll-crashing-cubase/802430

Nur um das auszuschließen:
Versuche doch mal temporär Cubase ohne externe Plugins zu laden
Das soll folgendermaßen funktionieren: Strg+Alt+Shift beim Starten der Anwendung drücken und den abgesicherten Modus ohne Plugins wählen (nicht ausprobiert). Wenn Cubase dann startet, kann es eigentlich nur an irgend einem toxischen Plugin liegen, welches beim Start mit angezogen wird.

 

[Whitenoisestudios]

@Joost : Danke für den Hinweis. Nach einem Crash beim Starten, wird beim nächsten Start ohnehin angezeigt, das Cubase gecrasht ist. Da kommt dann ein Abfragefenster wie man starten möchte(mit externen Plugins oder nur den Cubaseplugins und mit welchem Audiotreiber, sofern man mehrere Audiogeräte wie ich hat).

Dort habe ich schon alle Optionen ausprobiert - auch das Starten ohne externe Plugins. Hatte ich ja geschrieben. Vielleicht etwas misverständlich.

Ich probiere das mit Strg+Alt+Shift nochmal, um zu sehen, ob das noch einen Unterschied macht. Ich lebe halt im Moment einfach damit, dass ich Hyperthreading deaktiviert habe. Auf die Auslastung der DAW wirkt das bisher nach erster Einschätzung zumindest nicht großartig aus.

 

[recplay]

Hi, das hilft dir jetzt vielleicht nicht, aber ich habe ein ähnlich gelagertes Problem mit c13. War bei V13.30 und auch bei 13.40

Das Programm lässt sich nicht starten wenn ich Melda Plugins (neueste Version) installiert haben will. Ging eine Zeit lang bei 13.30 alles nomral bei mir, dachte alles ist ok- dann nach ein paar Wochen ließ sich C13 nicht mehr starten, gleich wieder weg nur graues Bild mit Fehler. Nach elendem Dumps durchsuchen war es klar dass bei mir Melda das Problem ist. Ich habe keine Zeit mich wochenlang mit sowas aufzuhalten. Ich habe aufgegeben und bin wieder zurück zu C12. Läuft problemlos und schaut besser aus. Leider

Bei mir läuft bei der 13 noch die Demo Version und ich bezweifle dass ich wechseln werde. Es läuft nicht gut und macht von den Neuerungen für mich nur wenig Unterschied.

Viele Grüße und viel Erfolg bei deiner Problemlösung.

 

[ollo123]

Hi, das hilft dir jetzt vielleicht nicht, aber ich habe ein ähnlich gelagertes Problem mit c13. War bei V13.30 und auch bei 13.40

Das Programm lässt sich nicht starten wenn ich Melda Plugins (neueste Version) installiert haben will.

Hmm, ich habe auch die Melda Plugins, müssten auch die aktuellsten sein und Cubase läuft auch in der aktuellen Version.

 

[mkzwoo]

Für mich hört sich das nach einem ''NET Framework Runtime'' Fehler an... Vielleicht ist dein Framework schon fehlerhaft, weil die aktuellste Version von Cubase nicht richtig läuft.. Die Version 13**+ laufen ohne Probleme...

Ein Versuch wäre es wert..

Microsoft .NET Framework Repair Tool is available - Microsoft Support

Describes the .NET Framework Repair Tool and how to obtain it.

support.microsoft.com

 

[recplay]

Hmm, ich habe auch die Melda Plugins, müssten auch die aktuellsten sein und Cubase läuft auch in der aktuellen Version.

Danke für die Rückmeldung. Es lief ja 1-2Wochen mit 13.0.30 - irgendwann dann eben nicht mehr. Irgendwann wird das schon wieder. C12 gefällt mir optisch immer noch wesentlich besser.

 

[NorthernDecay]

nur zur Info: Ich kann mit der Cubase 13.0.30 tadellos arbeiten, trotzdem habe ich gestern mal, das Windows NetFrame-blablabla… Reperaturtool drüberher gejagt und alle relevanten Systemtreiber erneuert. Dann habe ich einfach noch einmal die 13.0.40 installiert…der selbe Mist! Das liegt eindeutig an der neuen Cubase Version und meinem System, sonst gäbe es wohl mehrere Beschwerden (wobei, warum laufen alle anderen Versionen bei mir?).

 

[NorthernDecay]

Mahlzeit! Ich konnte nicht eher testen, darum erst heute die Info.
Das Update 13.0.41 hat mein Problem behoben… keine Abstürze mehr