JeremyNicoll

> I was looking in db file (SQL log), not the text files, which were written elsewhere. The db file is just the "forensic log". The logs created when you turn DEBUG on are placed in: C:\ProgramData\Emsisoft\Logs and - if you leave DEBUG on for long - can become very large.

> "I even turned DEBUG ON, but there is nothing interesting being logged" Did you disable debug logging afterwards so that the in-use sets of debug logs were closed (and new ones opened)? Also... unless you know what Emsisoft's code does, the meaning of return codes etc from their functions, I don't understand how you think you can tell what the flow of logic described in the debug logs actually means.

@GT500 OK; you say "When EAM's File Guard is configured for Thorough scan level, it scans every newly written file, If a file being extracted from the archive is detected as malicious, the File Guard responds to that just like it would for any other file." The point I'm trying to make is that EAM clearly knows it's scanning the file because it's been newly-written. That being so, the alert pane should look different from how it does when a file is being read for use or execution. In particular the two Allow options /should/ be clear on the huge difference in effect between 'Allow once' and 'Allow always'. Also, EAM knew in this instance that 7zip was the program that created the file. That info is invisible when you first see the alert pane; one needs to scroll the info. Obviously in this instance I knew what program had created the iffy file, but in the general case - when an arbitrary program creates a file that EAM thinks is bad - it would be much better for less-aware users if the alert pane said right at the start that program xyz.exe has just created file bad.doc ... and ideally also offered the option to terminate xyz.exe (or even just advised that a user might want to do that themselves, eg via task manager). The whole point of using EAM is to prtect users against themselves. This experience does not show EAM doing the best job it could do. Regarding single left click, and right-click on a file entry shown in WIndows Explorer, you said ""EAM was monitoring file system access, and detected the files were accessed". But I don't see why WE would need to open a file or get a handle on it etc just so that in WE a line showing a filename can be selected/editable. In the general case for right-click, I expect that either the file's full path, or a file system object gets passed to the chain of context menu handlers. I'm not sure that I'd expect any of those handlers actually to /access/ the file until a user actually selects a specific one off the menu. When one issues a "dir" command in a command window one wouldn't expect to have EAM scan the files contained in the folder, so why would trying to do a WE->Properties do that? At least for the basic Properties that WE itself displays? Clearly there's an extension mechanism there too (eg that digs ID3 tags out of .mp3 files) which DOES need a file to be accessed, but I'd have thought the bulk of the info presented comes from file metadata.

I didn't say that the alerts were "for" 7zip rather than the malware files. The alerts /were/ for the malware files. BUT, it was 7zip that I was running. The problems here are probably more an issue for @GT500 than you, though. I've repeated this. Downloading the .rar file with the samples in it causes no alerts. As soon as I asked 7zip to unpack the archive and provided the password, I got the first alert. (None of these alerts happen if FileGuard is set to its Default scan level - but I normally have "Thorough" set.) Two screenshots, of the alert's first pane and what you see if you scroll that down a bit: https://www.dropbox.com/s/ejwz0ovkpokevgk/20200111 Elise malware alert 01.jpg?dl=0 and https://www.dropbox.com/s/5twp18fwcbgaq1u/20200111 Elise malware alert 02.jpg?dl=0 This alert follows creation of the file: 0eb7ba6457367f8f5f917f37ebbf1e7ccf0e971557dbe5d7547e49d129ac0e98.doc Opening a Windows Explorer view of the extract-to folder shows that the file has already been created. When reading the meaning of the "Allow" options, which talk about "letting an action continue", that's misleading. Most alerts happen before a program is executed or a dodgy file is processed, when "continue" means let it run/be used. The descriptions of what "Allow once" and "Allow always" could be worded better for this situation. I think most users would regard "Allow once" and "Allow always" as differing only in the number of times that something is allowed. But in this case Allow once - lets the just-created file stay where it is Allow always - lets the just-created file stay where it is AND in future allow it to be used/run Creation of the file (by 7zip) is not in itself dangerous. But future use/execution is extremely dangerous. The distinction in meaning/effect of these two Allow options is nothing like clear enough. I do understand that there's a difference between EAM intercepting an attempted execution of something.exe, where the .exe itself is the danger, and eg a system utility (like part of the scripting framework eg wscript.exe) or a well-known interpreter (eg python.exe) or utility (eg i_view32.exe) reading a file and interpreting its contents. I /hope/ that EAM intercepts attempted execution of a .exe during "program load", or maybe while the .exe is being read prior to load. But in this case, although EAM did know that the parent process was 7zip (though it doesn't really matter what the parent was - the problem here affects any program that may create files), does EAM know that the alert is for a just-created file, something that is not being read prior to use/execution? As a matter of practicality, a user encountering a series of alerts as some unpacker or whatever creates a series of dodgy files could usefully be offered an option to terminate the program that is creating the files. If I hadn't been deliberately running 7zip to unpack these samples, I would rapidly have found it annoying to get alert after alert for every single file it created. As it was, even if I had clicked on "Allow once" (the safe choice of Allows here) I might have clicked on "Allow always" hoping that that would allow this instance of /7zip/ to keep creating files without generating alerts for each one. Again, clarity in the alert box about precisely what is being allowed would help. There's another problem. After (in my test recreation of this) I'd allowed the .doc file "once", EAM produced an alert for the next file (a .vbs one). At that point I looked at EAM's forensic log - see: https://www.dropbox.com/s/adbk1026u856457/20200111 Elise malware alert 04.jpg?dl=0 See the two log entries timestamped 23:21:33. The .doc file detection happened quite a lot earlier than the .vbs one, but they are listed in the opposite order. That's confusing. And another problem... Last night when recreating this I single-clicked one of the .vbs files' names, to highlight it so I could c&p its full name. Today, I right-clicked one prior to looking at its Properties pane. In both cases EAM generated an alert saying the file concerned was trying to execute. Last night that gave me a hell of a fright. I'm very very careful and had not thought I'd double-clicked the filename. Today I was absolutely certain it was a right-click. When it happened this morning I realised I'd probably been ok last night - the alert is badly worded. Can EAM not tell the difference between standard parts of Windows Explorer's context menu handling (selecting a file's name, or displaying its properties?) and an arbitrary context menu handler offering to do something with the file? [Last night, after the "trying to execute" alert, I clicked on Quarantine on that alert. EAM then told me it couldn't delete the "infection" and I needed to restart. I presume the problem would be that either another part of EAM had a handle open on the file, or maybe 7zip still did? During the reboot a boot-time file deletion was performed, and I did a second full shutdown immediately after that, then a cold reboot. I've also done a full-scan of the machine since then, and there's no sign of any malware.]

Which exclusions list did you add the program & folder to? The exclude-from-scanning one (no use), or the exclude-from-monitoring list (should work)? Also, has it recently worked alright? If it has (in which case it suggests a recently-released version of EAM is the problem), you might be able to tell EAM to use the 'Delayed Feed' (ie an older version of the program) rather than the more-uptodate one. You could try that by going to EAM's Settings - Updates - Update feed and choosing "Delayed", then choose "Update now" from the systray icon menu. If you do do this, as soon as you again reset the feed to "Stable" the newest version of EAM will again be installed. Sooner or later Emsisoft will ditch whatever older version is on the "Delayed feed" and a newer version will replace it, so - if this change does sort your problem - it won't fix it for ever.

@Elise - out of curiosity I downloaded the samples, unpacked the archive, and opened some of the files (the VBE, VBS and PowerShell ones) in a text editor. After looking at each of those, I right-clicked each one and selected 'Delete' - and EAM intercepted the placement of the file in the Recycle Bin (under the system-generated Recycle-Bin filename). But a right-click context scan of the unpacked archive didn't class those same .vbe/.vbs files as malware. I was surprised. Looking back through the log I think I found the reason. When I unpacked the archive, FileGuard told me about each malicious file, preventing the unpack from proceeding. I think I chose 'Allow always'. That seems to have added each of the unpacked files' full paths to my list of Exclusions. I suppose that explains why the files were not detected by a later scan of the unpacked folder... But... when I clicked 'Allow always', during the unpack, I thought I was allowing the unpack process to continue - specifically I was allowing that instance of 7z.exe to create files. I do not think that Allowing 7z to do something should translate into allowing the files it created to be excluded from future scans.

I don't know what "profile" means in what you describe - "an optional group of settings" perhaps? Google tells me that a feature of some/all Deco models is that it has built-in antivirus and scans all of your network's incoming and outgoing traffic.

Personally, I agree with you. But it's not clear whether Emsi will fix this or continue to say it's "working as designed". See discussion in this topic in the Beta forum, at: https://support.emsisoft.com/topic/32505-beta-9915/

Does EAM's memory use climb during the import and then decrease again (eg if it's building a new table while the old one is still there, then removing the old one)? How much real+virtual memory do @GT500 and @G11 have?

> We keep this info visible until user checked the scan results. The blue dot was visible (along with the 100% thing) here, all through yesterday - and maybe today too (until the Beta just updated - now it's gone), but I checked the most recent Custom scan's report, as soon as the scan completed. (Later: I suppose this was a series of blue dots after a series of context scans. But it adds nothing to my knowledge.) There's no way, in English, that you can reasonably claim that "New scan" is synonymous with "Close". "Close" means ending something whereas "New scan" implies starting something. Edited: I just tried a context scan of a few files. At the end of that, not having been told of any problems, the scan screen is displayed, saying "No suspicious files were detected during the scan." What else am I supposed to do to get rid of the blue dot? I have (a) not been told of problems /during/ the scan, and (b) been told there were no problems /at the end/ of the scan. Even if I choose to "view the report" - for which there is no reason because guess what? - it lists no problems - the blue dot is STILL being shown.

With Win 8.1, and build 9915, I see exactly what Marko describes. I do have separate 'Scan started' and 'Scan finished' log entries (eg for a custom scan earlier today of 1.4 million objects). Context-menu scanning a smaller number of files - first a folder containing 100 or so, then just a handful of files selected from a folder view, and finally just a single file ... all each produce a pair of log entries.

@Peter Nowell There's no protocol to violate, and you did not do any harm. I was just curious (as I thought my answer had been sufficient, and was provided only 14 minutes after you asked.) Seasonal greetings to you too.

@Peter Nowell Wy did you ask the question twice? And - if you didn't understand my earlier reply, why didn't you ask for clarification of what I said?

How big is the file you are importing? Does an import of a tiny file work?

Doesn't the decision to delete the key depend on whether or not @Daniel Pipe has the software concerned installed (intentionally) or not?