I have a desktop computer in my office with Windows 7 Professional (64 bit) SP 1, and my private laptop with Windows Home (64 bit) SP 1. MikTeX 2.9 full 64 bit version is installed on both of them, and both WinEdt 9.1 and WinEdt 10.0 are installed on them. This moment I am not actively using MiKTeX, however, I update it once a week (usually on Wednesday).

The last update went seemingly smoothly on desktop computer but failed on laptop; the update procedure stopped with error message "too meny files". Initially the launch of MiKTeX Options (Admin)" -> "Refresh FNDB crashed with the same error message. Today I tried to do it once more and seemingly all finished O.K. but now on my laptop in both WinEdt 9.1 and WinEdt 10.0 the menu choice "Options" -> "Execution Modes..." -> "TeX System" leads to nonexistent folder C:\MiKTeX as TeX Root if Auto-detect is used. I corrected manually TeX Root to the correct folder C:\Program Files\MiKTeX 2.9, but independently on the value of TeX Root the trial compilation of correct .tex file (one of my published scientific papers) lead to immediate error - unability to find entry point into MiKTeX209-core.dll.

Warried by all this, I went to my office, in order to test my desktop computer. As usually, I downloaded the newest Norton 360 (antivirus program) updates and then opened both WinEdt 9.1 and WinEdt 10.0. TeX Root was correct in both of them. However, when I tried to compile the same .tex file (my published paper), the translation finished with 0 error messages and 0 output pages. Few seconds later Norton 360 gave the message that its SONAR monitoring function has noticed "suspicious behavior with high risk" of C:\Program Files\MiKTeX 2.9\miktex\bin\x64\amstex.exe and automatically removed the threat (in fact, quarantined it). My .tex file uses both packages amsmath and amssymb indeed; probably amstex.exe is absolutely necessary. Now if I try to compile .tex file I get the following log file:

Command Line:   pdflatex.exe --interaction=errorstopmode --synctex=-1 "Cylindrical_eigenfunctions.tex"
Startup Folder: E:\Papers\JQSRT\MiKTeX_parbaude_2016_05_15

Error Launching Console Application PDFLaTeX ...
Command Line:   pdflatex.exe --interaction=errorstopmode --synctex=-1 "Cylindrical_eigenfunctions.tex"
Startup Folder: E:\Papers\JQSRT\MiKTeX_parbaude_2016_05_15

I seem it is even not worth to try to reinstall MiKTeX because if amstex.exe is evaluated as highly suspicious by Norton 360 SONAR function then it will be quarantined each time when it is launched.

  • You can show Norton who's boss…
    – Bernard
    May 15, 2016 at 14:07
  • Did you check the PATH?
    – Bernard
    May 15, 2016 at 14:10
  • I use Symantec Norton products for many years as my standard antivirus software. Of vary many various programs which have been installed on my computers, only 2 times Norton SONAR function has intervened and quarantined anything. First time it was several years ago - MiKTeX updater copystart_admin.exe was quarantined (soon it was updated and now it works well), and the second time is now - amstex.exe. It means Norton 360 SONAR generally is not excessively agressive, and amstex.exe should be updated in such way that it does not do suspicious actions. May 15, 2016 at 16:22
  • In the meantime, you can compile with pdflatex.
    – Bernard
    May 15, 2016 at 16:27
  • amstex.exe is certainly not needed for a normal pdflatex run. May 15, 2016 at 17:59

1 Answer 1


amstex.exe was essentially superseded in the mid-1990s by a latex implementation; therefore amstex.exe is needed only for legacy documents. if you didn't start using (la)tex until after 2000, you can safely ignore amstex. nonetheless, it's rather puzzling why amstex.exe would be flagged, but none of the other tex binaries.

the reason for the quarantine would best be investigated by someone from the miktex world, who has a better understanding of what norton antivirus is doing. the format-specific executables such as amstex, latex, etc., all contain dumps of tex's internal memory structures after the corresponding format has been loaded. presumably there is some sequence of tokens (or something similar) somewhere inside amstex.tex that, when converted into tex's internal representation, generates a sequence of bytes that norton finds suspicious. it would probably take quite a bit of detective work to figure out what that is, and even if we could, there's not much we could do about it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .