JeremyNicoll

Member
  • Content Count

    1771
  • Joined

  • Last visited

  • Days Won

    26

Posts posted by JeremyNicoll


  1. Last night my Win 8.1 64 bit system had a BSOD stop code 0x000000d1 ie "DRIVER_IRQL_NOT_LESS_OR_EQUAL" apparently in tcpip.sys

    At the time I wasn't consciously doing anything internet-ish though I did have browser tabs open.   There's no obvious reason to blame EAM, except that I know there's maybe an ongoing problem in this area.

    I have a full 8 GB dump from this.  Do you want it?


  2. Looking at the KB articles implies SHA-2 support for Win 8.1 was shipped a long time ago (the article at https://support.microsoft.com/en-gb/help/4472027/2019-sha-2-code-signing-support-requirement-for-windows-and-wsus says there's no specific action required for Win 8.1, which probably means the support was included in something else, earlier).

    Maybe relevant though is that over the last 6 months or so there's been several updates to what Microsoft call SSUs ie "Servicing Stack Update"s.   I only know about these because I read the "More information" pages listed by Windows Update for each available update.  These SSU updates DO NOT GET LISTED in the list of available updates in Windows Update  if, when you check to see if any updates are pending, other updates are.  So, to get the SSU updates installed, you have to "Hide" (by right-clicking listed updates and choosing to hide them) other normal updates.  Then WU will magically offer the SSU update (and presumably afer each one, the next one - unless it just installs the most recent one).   After all that, and another "check" to make sure nothing else is pending, you can unhide whatever you hid.  So possibly something like that may mean (if you're installing updates when you want to, rather than when MS makes them available) that you're a long way behind on these ones.

     


  3. This instance was broadly similar to the one discussed in:

    https://support.emsisoft.com/topic/27330-system-hang-after-suspicious-activity-box-could-not-be-dismissed/

    The VBS script merely issues:

      set objShell = CreateObject("shell.application")
      objShell.Explore(usefoldr)

      to open a File Explorer view of a folder, in this case C:\ProgramData

    I /really/ don't understand why the BB regards opening a File Explorer view of a folder - any folder - as suspicious.  It's only a picture of what's in the folder, and I can navigate to that folder and open it without Administrator authority.   The script is just acting like a shortcut.


  4. Win 8.1, EAM version...  whatever it was 11 days ago - can't tell because I didn't note it down and my forensic log file doesn't go back that far.

    This was another instance of EAM warning me about suspicious behaviour in one of my VBS scripts, but no action buttons appearing on the warning pane, and a continuous eggtimer if I moused over it.

    As always I am not complaining that the BB raises an alert.  I /am/ complaining that the only way out of it is to power off the machine, or  - as I did - forcing a BSOD to get a dump.

    I /really/ hate having to do a power-off or a BSOD as both risk damage to the file system.  Open files don't get written back to disk properly, and so on.

    This problem has happened on and off for years, gets fixed, and comes back again.  Presumably it's not just my VBS script that could cause this?  Surely any instance of a BB alert (and perhaps a failed attempt to look the causing program/script up on the AMN - in previous instances I've had the impression that was being attempted though this time around I don't know if I saw anything saying so - can cause this hang?  Maybe someone needs to look at the overall logic not just whatever the immediate cause of the hang this time was?

    There are no eventlog records from the time of the hang describing anything EAM-ish.  There are eventlog records from other apps that hung just afterwards when eg I tried to save a screenshot... 

    Anyway I'll pm the location of the dump (around 8 GB uncompressed, 1.6 GB compressed) to @GT500  once it has uploaded fully.


  5. While looking more closely at logs from recent custom scans, I noticed that the line that they used to contain:

    File extension filter: Off      (or On)

    vanished from those log files sometime in April, in fact when EAM v 2020.5 came along (released in beta, in April; general release early May).

     

    Exploring now, I can't find any settings in Custom Scan, or File Guard or anywhere else for extension-specific logic.  The release blurb for v 2020.5: https://blog.emsisoft.com/en/36082/new-in-2020-5-local-only-local-remote-or-remote-only-security-management/  seems to have been completely silent on this loss of control, unless you think that "Cleanup of redundant settings." is an adequate description.

     

    Is this level of control gone for good?

    Do File Guard and/or Custom Scan now look at every kind of file?  Or is there a changing definition (that we can't see) of which files get looked at / guarded?

     

     


  6. Someone who knows more than me will need to comment.  It's odd that EEK, using (according to its log) uptodate definitions, thinks - it seems - that one of these files is iffy. 

    On the other hand, all those a/v products, including EAM, think the files are ok. 

    That makes me wonder if there was ever another file involved - can EEK quarantine things?  I don't know.  Or if a directory itself can somehow be infected? 

    I note also that the EEK scan did look in Alternate Data Streams.  If any of these font files have an ADS, I don't know if that would have been uploaded to VirusTotal along with the principal content of the files.   You could use: https://docs.microsoft.com/en-gb/sysinternals/downloads/streams  to see if any of the file do have an ADS, or (if you prefer a GUI): https://www.nirsoft.net/utils/alternate_data_streams.html

     


  7. @bluescreen  You might be able to tell from EAM's logs (assuming they survived uptodate across the termination), or failing that date & time stamps on its updated program files, precisley when the new version got installed.  If the 'System' Eventlog records that mention services terminating are at the same time, maybe it is just one of those things - an update that didn't go as planned.  But if the times are different then the contents of the System Termination log records might be useful.  If you click on each one there'll be a "Copy" button in the pane that opens, that will let you copy its contents here.


  8. You could try uploading each of the three font files to VirusTotal  - see:  https://www.virustotal.com/gui/home/upload - and make sure you use the "File" tab there.   Their system will let lots of different antivirus products examine the files, and tell you what it thinks about each one.  If it's clear that most of all of the other products think the files are fine, it'd be useful to Emsisoft if you'd post the URLs of the three VirusTotal reports into your next reply.  

     


  9. 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\


  10. @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?