bug#52295: 28.0.90; Killing text results in coding system complaint

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 18 Dec 2021 08:48:07 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 52295@debbugs.gnu.org
> 
> If it's a real crash, you could use the Windows Event log to find out
> the address where it crashes, and then use GDB on another system to
> see where that address is in the sources (but the address printed by
> Windows needs to be "translated" into addresses that you submit to GDB
> by adding some constant, AFAIR).
> 
> The other alternative is to insert many fprintf's to stderr into the
> sources, and use that to determine where it crashes.
> 
> If it's an abort, then saying NO to the dialog will produce an
> emacs_backtrace.txt file with addresses of the backtrace, which you
> could take to another Windows system and use addr2line (from Binutils)
> to recover the file names, function names, and line numbers that
> correspond to the addresses; see the node "Crashing" in the Emacs
> manual for how to do that.

Btw, there's one more alternative: to debug Emacs on Windows 9X
remotely, via gdbserver.  Did you try that?  The advantage is that
gdbserver is a much smaller and simpler program, so chances are it
will be able to run on Windows 9X.  GDB itself will run on a different
system (could even be GNU/Linux, if you have GDB that was built to
support debugging Windows PE executables), where all the problems of
running a modern GDB don't exist.  You just need the target system to
be connected to a network, so that GDB and gdbserver could
communicate.