The reason is actually not related to desktop-save. Unfortunately it is not easy to reproduce, as the behavior is not consistent. With the following recipe it shows quite regular though: * Open a Windows Terminal, either Windows Terminal with bash or directly cmd.exe; Didn't test with powershell. * Run emacs -Q -nw * M-x speedbar-get-focus * Right-click with the mouse, so the speedbar menu displays <-- this step *seems* to trigger the bug more easily Now the behavior is not consistent, either * Emacs enters a spin-lock and doesn't react; OR * Emacs crashes with a backtrace; OR * Emacs continues without any issues. I did however also notice in the past that Emacs on Windows (builds from https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-29/) had spurious crashes on other places, albeit only when running with -nw. So there might be a nasty (Windows - only) terminal display bug? I do attach the backtrace and hope that it might be useful. -----Ursprüngliche Nachricht----- Von: Eli Zaretskii Gesendet: Dienstag, 18. Juli 2023 18:25 An: Höchtl Johann | WKO Inhouse Cc: 64710@debbugs.gnu.org Betreff: Re: bug#64710: 29.0.92; desktop session on terminal with speedbar crash > From: > Date: Tue, 18 Jul 2023 12:14:09 +0000 > > This crash affects 'GNU Emacs 29.0.92 (build 1, x86_64-w64-mingw32) of > 2023-06-19'. > > When I start emacs in Windows Terminal (OpenConsole host) with -nw > with a saved desktop, Emacs loads that session. When I start speedbar > with > > M-x speedbar-get-focus > > Emacs crashes after very short time with a backtrace. The likely > reason is that speedbar information cannot be saved on a terminal in > the desktop file. Can you describe the recipe in more detail? Specifically: . did you save the desktop from GUI session or -nw session? . did you have Speedbar frame in the session from which you saved the desktop? If you could present a complete recipe starting from "emacs -Q" or "emacs -Q -nw", that would help a lot to understand the problem. Thanks. Datenschutzerklärung