Update: PROBLEM SOLVED (but mystery remains)
I verified that file size had nothing to do with the crashes: it happened on the second PDFTeXify cycle with even a 3 MB file.
SOLUTION: The change I just made was in the
WinEdt settings: Options —> Execution Modes… —> PDFTeXify —> UNCHECK “Start Viewer”.
I now have to manually open SumatraPDF and then the PDF file, but each new PDFTeXify cycle is now updating SumatraPDF without it crashing.
The mystery of what’s actually going on remains, but at least (selfishly) I am back in business!
I would still like to really get to the bottom of this, because of these two downsides to not having WinEdt launch SumatraPDF:
I have to manually switch the focus to SumatraPDF after each PDFTeXify cycle.
The PDF does not open at the place I was editing, because “forward search” is a sub-option of the (now-disabled) “Start Viewer” option.
Update of update:
SOURCE OF CRASHING FOUND?
To overcome the two problems (1) and (2) above, I tried doing a manual “Forward Search” using
WinEdt: Shift + F8
This immediately caused SumatraPDF to crash!
[Of course this does nothing to explain why everything was working perfectly for three days with “Start Viewer” and “forward search” enabled!]
KJK: Thank you for explaining what you meant by “press cancel”. However, no such crash-report window appears after my “crashes”, so perhaps they are not crashes after all. As I have explained, I know nothing about programming, but could it be that WinEdt’s “Start Viewer” and/or “forward search” is being received by SumatraPDF as a (lawful) command for SumatraPDF to Close/Exit?