Fix bug #12908 with documentation of emacs_backtrace.txt on MS-Windows.

doc/emacs/trouble.texi (Crashing): Add information about MS-Windows and
 the emacs_backtrace.txt file.

 etc/NEWS: Mention emacs_backtrace.txt.

doc/emacs/ChangeLog

@@ -1,3 +1,8 @@
+2012-11-16  Eli Zaretskii  <eliz@gnu.org>
+
+	* trouble.texi (Crashing): Add information about MS-Windows and
+	the emacs_backtrace.txt file.  (Bug#12908)
+
 2012-11-13  Chong Yidong  <cyd@gnu.org>
 
 	* building.texi (Multithreaded Debugging): gdb-stopped-hooks is

doc/emacs/trouble.texi

@@ -282,18 +282,23 @@ itself, and the reserve supply may not be enough.
 @subsection When Emacs Crashes
 
 @cindex crash report
+@cindex backtrace
+@cindex @file{emacs_backtrace.txt} file, MS-Windows
   Emacs is not supposed to crash, but if it does, it produces a
 @dfn{crash report} prior to exiting.  The crash report is printed to
 the standard error stream.  If Emacs was started from a graphical
-desktop, the standard error stream is commonly redirected to a file
-such as @file{~/.xsession-errors}, so you can look for the crash
-report there.
+desktop on a GNU or Unix system, the standard error stream is commonly
+redirected to a file such as @file{~/.xsession-errors}, so you can
+look for the crash report there.  On MS-Windows, the crash report is
+written to a file named @file{emacs_backtrace.txt} in the current
+directory of the Emacs process, in addition to the standard error
+stream.
 
   The format of the crash report depends on the platform.  On some
 platforms, such as those using the GNU C Library, the crash report
 includes a @dfn{backtrace} describing the execution state prior to
 crashing, which can be used to help debug the crash.  Here is an
-example:
+example for a GNU system:
 
 @example
 Fatal error 11: Segmentation fault
@@ -320,22 +325,24 @@ backtrace with source-code line numbers:
 
 @example
 sed -n 's/.*\[\(.*\)]$/\1/p' @var{backtrace} |
-  addr2line -Cfip -e @var{bindir}/emacs
+  addr2line -Cfip -e @var{bindir}/@var{emacs-binary}
 @end example
 
 @noindent
 Here, @var{backtrace} is the name of a text file containing a copy of
-the backtrace, and @var{bindir} is the name of the directory that
-contains the Emacs executable.
+the backtrace, @var{bindir} is the name of the directory that
+contains the Emacs executable, and @var{emacs-binary} is the name of
+the Emacs executable file, normally @file{emacs} on GNU and Unix
+systems and @file{emacs.exe} on MS-Windows and MS-DOS.
 
 @cindex core dump
-  Optionally, Emacs can generate a @dfn{core dump} when it crashes.  A
-core dump is a file containing voluminous data about the state of the
-program prior to the crash, usually examined by loading it into a
-debugger such as GDB.  On many platforms, core dumps are disabled by
-default, and you must explicitly enable them by running the shell
-command @samp{ulimit -c unlimited} (e.g.@: in your shell startup
-script).
+  Optionally, Emacs can generate a @dfn{core dump} when it crashes, on
+systems that support core files.  A core dump is a file containing
+voluminous data about the state of the program prior to the crash,
+usually examined by loading it into a debugger such as GDB.  On many
+platforms, core dumps are disabled by default, and you must explicitly
+enable them by running the shell command @samp{ulimit -c unlimited}
+(e.g.@: in your shell startup script).
 
 @node After a Crash
 @subsection Recovery After a Crash

etc/NEWS

@@ -210,7 +210,9 @@ This minor mode replaces `toggle-read-only', which is now obsolete.
 ** Emacs now generates backtraces on fatal errors.
 On encountering a fatal error, Emacs now outputs a textual description
 of the fatal signal, and a short backtrace on platforms like glibc
-that support backtraces.
+that support backtraces, and also on MS-Windows.  On Windows, the
+backtrace is also written to the 'emacs_backtrace.txt' file in the
+directory where Emacs was running.
 
 ---
 ** If your Emacs was built from a bzr checkout, the new variable