Ich schrieb, ich glaube nicht, dass dies die Lösung deines Problems ist.
Das ist ohne Wertung formuliert. Nur eine Vermutung, die ich geäußert habe, ohne da irgendwas unterstellen zu wollen.
Das ist unqualifizierter Mist. Wavelab benutzt so wie alle andere Software auch die vom OS bereitgestellten Methoden, um auf Datenträger zuzugreifen.
Nur so am Rande: Du hast auf “Das Problem tritt auf, wenn ein Netzlaufwerk nicht verbunden ist.” mit “Ich glaube nicht, dass dies die Ursache deines Problems ist.” geantwortet.
Aber wie dem auch sei. Vielleicht hast du dich verschrieben und ich hab überreagiert.
Hab heute nicht meinen besten Tag, sorry. Lassen wir es dabei.
Zu meinem “unqualifiziertem Mist”:
Natürlich verwendet WaveLab die Funktionen des Betriebssystems. Die Frage ist aber wie man das macht. In der Regel macht der MainThread eines Fensters nicht viel anderes als die Nachrichtenschlange abzuarbeiten. Vereinfacht gesagt, ruft er Routinen auf, die einem Ereignis, z.B. einem Tastendruck, zugeordnet sind. Als Programmierer muss man darauf achten, das diese Routinen nicht zu viel Zeit benötigen, weil mit Sicherheit schon die nächste Nachricht wartet. Es gibt da nicht nur Ereignisse die vom User ausgelöst werden sondern auch z.B. Aufforderungen zum Neuzeichnen eines Fensters oder Steuerelements usw. Kehrt jetzt eine Routine nicht zurück, so werden die wartenden Nachrichten nicht abgearbeitet und es sieht für den User so aus, als würde die Anwendung hängen, weil sie weder auf Klicks o. Tastatureingaben reagiert und auch der Fensteraufbau nicht mehr funktioniert. Ich denke das du das bestimmt schon einmal gesehen hast. Zeitintensive Routinen sowie Routinen bei denen fremde Funktionen, z.B. des Betriebssystems, aufgerufen werden, bei denen man sich nicht sicher sein kann das sie fix erledigt sind (z.B. einige Filesystem- und Netzwerk-Funktionen), programmiert man in einen eigenen Thread. Der wird in der Routine dann nur gestartet und läuft asynchron zum Thread des Fensters. Die Routine kann sofort zurückkehren und die nächsten Nachrichten werden bearbeitet. Natürlich macht es dem Programmierer dann noch ein bisschen Arbeit. Denn der zusätzliche Thread muss ja irgendwie seine Ergebnisse dem Thread des Fensters mitteilen und asynchron ist das Ganze auch noch. Als Programmierer sagt man sich da schnell “Och, ich scanne ja nur mal eben die vorhanden Laufwerke, da gibt´s ja einen Befehl dafür und das dauert ja nicht lange, da erspare ich mir den Aufwand mit einem extra Thread”. Das funktioniert so auch fast immer. Aber dann kommen ein paar unglückliche Umsände dazu, die Funktion des Betriebssystems braucht Ewigkeiten bis sie zurückkehrt, die Nachrichtenschlange wird nicht mehr abgearbeitet und die Anwendung hängt. Vielleicht verstehst du jetzt was ich meine. Zu meiner Schande muss ich gestehen, dass ich das auch schon mal so verbockt habe.
Seltsam ist nur, dass nicht mehr User so ein Verhalten melden und deshalb frage ich mich, was an deinem System nun so besonders ist, dass es sich so verhält.
Und danach stellt sich mir die Frage, wie man evtl. dieses Problem abstellen kann, ohne den Code andere Software an dein System anzupassen.
Nur mal so laut gedacht …
Ich habe leider auch ein ähnliches Problem.
Gestern liess ich eine Stapelbearbeitung laufen und es sollten etwa 1500 m4a Dateien in mp3 umgewandelt werden. Nach etwa 600 erfolgreichen Konvertierungen gab es für die noch fehlenden Dateien nur noch Fehlermeldungen.
Nach einer Weile habe ich auch herausgefunden warum: Der Speicher c: war offenbar voll. Leider weiß ich nicht woher das plötzlich kam, und was das für Daten sind. Irgendwelche temp Daten?? Wenn ja wo speichert Wavelab die?
Naja, weiter: Um später an der Stelle weiter zu machen, wollte ich nun die Staplebearbeitungsliste abspeichern. Und mit dem Klick stürzte Wavelab ab.
Von dem Moment an ließ sich Wavelab 12 Pro nicht mehr starten. Man sieht kurz den Startbildschirm und nach “Lizenzen werden geprüft”, wird das Programm beendet. (Die Lizenzen sind natürlich nich das Problem). Es würde wohl im Anschluss etwas geladen werden, was dann nicht klappt oder so.
Löschen von Daten um wieder Speicherplatz zu schaffen , oder Neuinstallation von Wavelab haben nicht geholfen.
Hat jemand eine Idee was da los ist? Ich habe auch die Datei der Stapelbearbeitung nicht finden können, ich denke das Speichern hatte Wavelab nicht geschafft vor dem Absturz.
Das ist ein ganz anderes Problem als oben beschrieben …
Evtl. kann dir da @st10ss einen Hinweis geben 
Wavelab speichert bei Stapelbearbeitungen Daten zwischen. Nach dem ordnungsgemäßen Beenden von Wavelab sollten die eigentlich gelöscht werden. Ich vermute, deine Liste mit den Dateien ist zu groß gewesen.
M4A Dateien sind auch manchmal nicht konvertierbar, da Copyright Flags gesetzt sein könnten.
Ja verstehe. Wo wären denn diese zwischengespeicherten Dateien? Ich habe dazu nix gefunden.
Da Wavelab ja abgestürzt ist, wurden die Dateien wohl auch nicht gelöscht, so dass die Festplatte noch komplett zugemüllt war. Ich achte da ja drauf, das ich genug Platz habe. Kann mir das absolut nicht erklären, dass auf einmal so ein Speicherproblem auftauchte.
Habe nun in Appdata/Roaming Steinberg mal die Dateien von vor dem Absturz gelöscht. Jetzt startet Wavelab zumindest grad und scannt die PlugIns neu. “PlugIns werden geprüft”. Mal sehn ob es danach weiterläuft….
PS danke erstmal für die Antworten so far. 
So, also Wavelab läuft wieder nachdem ich die Appdata Sachen gelöscht habe. Welche der Dateien genau, verantwortlich war ist Spekulation. Naja, hier ne Liste der Dateien, die nach dem Neuinstall noch vorhanden waren, und die ich dann von Hand gelöscht hatte. Jetzt läuft es wieder und ich versuche jetzt die restlichen 6-700 Dateien zu konvertieren.
L Ö S U N G gegen Einfrieren G E F U N D E N … eigentlich ganz einfach und funktioniert unter Win 10 und Win 11 gleichermaßen 
Wie es eigentlich immer der Fall ist, liegt der Fehler immer an dem DAU, der VOR dem Rechner sitzt:
Um zu vermeiden, dass WaveLab ständig einfriert, muss die AUDIOVERBINDUNG KORREKT eingestellt sein!
Unter DATEI / VOREINSTELLUNGEN / AUDIO-VERBINDUNGEN muss als AUDIOGERÄT der “Steinberg built-in ASIO Driver” eingestellt sein. Andere ASIO-Treiber bewirken sofortiges Einfrieren.
… als DAU frage ich mich, warum der “Steinberg built-in ASIO Driver” Treiber bei der Installation nicht per DEFAULT eingestellt ist …? Könnte Einiges vereinfachen 
Vlt. hilft der Beitrag ja trotzdem dem Einen oder Anderen, der auch schon seit Monaten mit dem Vorschlag-Hammer vor der Kiste steht
Anbei ein paar Screenshots, wie die Einstellungen jetzt aussehen….
Hi,
ist zwar schon ein paar Monate her, aber ich kann deine Lösung ebenfalls bestätigen. Bei mir war die Ursache ebenfalls ein Netzlaufwerk welches nicht mehr verbunden war.
Vorher hatte ich auch schon den Virenscanner deaktiviert und auch die Audioverbindungen durchprobiert. Aber das führte zu keiner Lösung.
Die Lösung war das getrennte Netzlaufwerk komplett zu entfernen (entweder per net use delete oder über den Explorer)!
Der Forumseintrag hier hat mir also bei der Lösung meines Problems sehr geholfen.
LG
Ralf
