<awards self a blue ribbon for 3rd place> >From SNFclient.exe.err I saw these errors repeated for every message processed: 20120107155711, arg1=C:\IMail\spool\proc\work\D016759002.smd : Could Not Connect!
The srvany.exe was running, but the SNFserver.exe wasn't, or wasn't healthy. Each SNFclient.exe had to read the .gbx file itself and process mail (I think) as they could not connect to the local server. There was no logging to the licence.date.log file. There was no update to the .gbx file, because SNFserver.exe does this work, and either wasn't running or wasn't listening on port 9001/TCP. Stopping the MessageSniffer Windows service, making sure that srvany.exe and SNFserver.exe weren't running and deleting the .state file then restarting the service: same result. Stopping the MessageSniffer Windows service, making sure that srvany.exe and SNFserver.exe weren't running and deleting the .state file then starting manually with: SNFServer.exe C:\MessageSniffer\snf_engine.xml resulted in the error message: SNF Server Version 3.0 Build: Jun 26 2008 13:25:19 SNFMulti Engine Version 3.0 Build: Jun 26 2008 13:25:06 Launching with C:\MessageSniffer\snf_engine.xml Unhandled Exception: _snf_LoadNewRulebase() TokenMatrix::BadMatrix Thrown! at this point I didn't even look at the rulebase size or date, I made sure SNFserver.exe wasn't running, then ran my old UpdateSniffer.cmd script, which still worked. I started the Windows service, and sniffing was back to normal. The lesson here for me is to put the update script back into service, but to only try downloading if the rulebase is old enough to be suspicious. If there's here for the SortMonsters, it's to make sure that a "bad matrix" error doesn't interfere with downloading a fresh rulebase so that SNFserver.exe can get itself out of that jam. Andrew from Vancouver
