JeremyNicoll

Does EEK have a log? If so does it show more info if you double-click the line saying there's a detection? One might hope for the name of the supposedly-infected file. Also, in your File Explorer settings, do you have the option to display hidden files turned on? (That should, if W10 is like W8.1, be in the View tab of File Explorer's Options dialog.)

@bluescreen - can you find any eventlog records describing a2start terminating (if it did)? No cpu use in the other tasks too is worrying.

For info, really... I finally got around to changing the registry keys concerned so that application dumps will be 'full' ones (ie as detailed as possible). I know you've got .reg files that make that change for those who wish it, and nominate %PUBLIC%\CrashDumps rather than the Windows default of: %LOCALAPPDATA%\CrashDumps as the place to which dumps will be written. There's clearly a small risk (with the %PUBLIC% location) that - on a system with multiple users - someone unauthorised could read a dump created on behalf of another user. Maybe you should highlight that? I took ages to set this up because I also read in detail around the subject of "Windows Error Reporting" (which is the bit of Windows in which support for different types of user dump is implemented), and wrote notes for myself about all of this. For these dump options, see: https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps My eye was caught by the text that says that the nominated location only applies to dumps from applications being run /by users/, ie not dumps from services. It says that service dumps will be elsewhere and does not give a full list of those locations ... except that they'll be somewhere inside %WINDIR%. In a command prompt opened with Admin authority, the command: dir /b /s %WINDIR%\*.dmp* will search through all the possible places that might contain such dumps and list where they are. I found 24 dumps I didn't know existed... mostly pretty old. Some of them were from a2service.exe ... and those (here anyway) were in: C:\Windows\System32\config\systemprofile\AppData\Local\CrashDumps\ None of the folders containing service dumps are (on Win 8.1 anyway) able to be opened in File Explorer unless you have Admin authority. The other places (not explicitly listed as possibilities in that MS document) in which I found service dumps were: C:\Windows\LiveKernelReports\WATCHDOG\ C:\Windows\LiveKernelReports\WinsockAFD\ C:\Windows\SysWOW64\config\systemprofile\AppData\Local\CrashDumps\

There's really no point in having a "beta" that is only available for a few minutes before it becomes "stable". Compare this with @GT500 's comment (about a possible "Malwarebytes" release) at: https://support.emsisoft.com/topic/33669-possible-program-conflict-leading-to-bsod/?do=findComment&comment=206229

@andrewek - excuse me, but I am confused. Is "Well, bravo, Emsisoft!" a happy statement or an unhappy/cynical one? I can't tell from your picture whether it shows what you want it to look like ro not. Also "Obviously, a small one has been fixed - but the problem with maintaining the window size of the program (interface)." - is only half a sentence. Is there meant to be more? "But" what?

Ah, excellent! Thank-you.

Which current beta? The one we've been running for days, or the one released 15 minutes ago? (it's a bit soon to say for the latter. For the former, yes it was still not perfect, as I reported on the Beta forum.)

Your second line down ... C:\Program Files\Emsisoft Anti-Malware ... is enough (for EAM) because that's where the various a2- & epp- .exe programs (and DLLs etc) live. You shouldn't need to exclude any C:\Program Data\... folders, at least not the Emsisoft one, as the whole point of a ProgramDATA folder is that it is not meant to contain any executable programs, just data files that programs use. I don't know what's in the C:\ProgramData\Dell Inc, or C:\ProgramData\SupportAssist folders though. If they actually do contain executable programs rather than just data they may need to be in the exceptions list.

Did you mean a window that looked like the following - white, black text, red icon? (Ignore the fact that this example is for some other program.) @GT500 - if this was an EAM failure, should there have been an Eventlog record?

@Nikilet - you should be able to find some info in an Event Log, using the Event Viewer. In Win 10 you can find that by typing in "Event Viewer" in the search box. Be aware that the event viewer shows contents of normal reports of all sorts of things going on in the OS. For example it's common for bits of Windows to try something, fail (perhaps because something else is going on at the same time), and the bit that failed will be retried later and work. Failures do not mean there's something wrong. [Most of the technical support scams (ie when someone phones you and claims they are from Microsoft or your ISP, and your computer has a problem) use this perfectly normal list of apparent errors to convince people that there's a problem with their system.] These logs are really normally only of interest to programmers. Anyway, if you can find Event Viewer as suggested above, and start it, you'll probably be asked for the system's Admin password. That's because some of the logged info is in files normally only accessible by the Admin user. It's fine to give the password. Then - if the viewer is like the one in Win 8.1, it will open with a small list on the lefthand side saying Event Viewer (Local) - Custom Views - Windows Logs - Applications and Services Logs Subscriptions Click on "Windows Logs" and it should expand to show Application Security (maybe) Setup System Forwarded Events Click on "Application". The display's central panel should then show a long list of log entries, and the date and time they were created at. Scroll the list to find any that are as close as possible to the time you think EAM had the problem. They /might/ have "Emsisoft" named in the "Source" column, but then again they may not. If you can't find any in the "Application" set, look also in the "System" set. Look at anything whose date & time is around the right time. If you double-click an entry in the long list of entries it will open and show more information. Don't expect it to mean anything to you. Ideally you're looking for any of these "event logs" that mentions EAM or Emsisoft, and possibly also words like "exception". If you find any, there should be a button labelled "Copy" - in the Win 8.1 version it's at the bottom lefthand corner of the box with all the extra cryptic information. Click on "Copy" then paste the results into a reply here. If there's lots of records that all seem EAM-related have a look to see if they all say similar things. Examples of each type of thing will be useful.

I've waited a few days to see how 10259 seems to be behaving and it's certainly looking a lot better - cpu has stayed low. However I just got to teh end of a custom scan - which was long running - just over 4 hours; two drives (both SSDs, though one is fairly empty), 1.4 million files. The scan looked inside archives which is why it took so long (a scan of the same disks but skipping archives usually takes around 70-75 minutes). Also debug logging is on. But, see this summary from Process Hacker. A2start, during the scan had a WS of 1.1 GB, and still does now that the scan is finished. It peaked at 1.11 GB and peak virtual memory use was 1.41 GB. It's a hell of a lot for a process that's supposedly only doing the user-facing stuff. When I was watching the scan running, near the end, a2service - the bit that as far as I know is actually doing the work - was using around 770 MB. I don't understand how a2start can be using more memory then the scanner itself.

Whether a system restarts after a BSOD depends on a setting in (at least in W8.1 - the options might have different names in W10): Control Panel - System - Advanced System Settings - Startup and Recovery - Settings - System failure ... where you can choose whether "Automatically restart" is selected. Some people like a failed system to restart, others hate it. In particular some kinds of problems can cause a continual loop of crash, restart, crash, restart, crash, restart ... Also, some people (eg me) will always do some extra things (look for dumps, look for eventlog records, run chkdsk full scans...) after any BSOD and really would not want the machine to just restart. Depending on what you normally have a machine set up to do when restarted it might be easy not to notice that BSODs had occurred. Why would a WIFI problem have anything to do with your ISP? They may have provided the WiFi router that you connect to, but that would be a hardware problem in your home with that router, not a problem in the ISP's own network.

It's not what I meant. Doesn't MS release new versions of Win 10 every 6-8 months? I wondered if both machines had the same version. After that, I'd also wonder if both of them are uptodate with Windwows Updates.

Do those both have the exact same version of Win 10 on them?

I only have the small dump that I already sent.