JeremyNicoll

EAM hang (11 days ago, previous version)

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

I've forwarded this to QA.

Do you also have debug logs? They're going to want those as well.

Share this post


Link to post
Share on other sites

It looks like the issue may be EPP related, however there are other changes that need to be made to EPP first, so we won't be able to look into this right away.

Share this post


Link to post
Share on other sites
20 hours ago, JeremyNicoll said:

Any progress?

Unfortunately we won't be able to make any progress on it for a little while. The current EPP is going to be updated in the (hopefully) near future, and we're currently focusing development and QA efforts on getting it ready ASAP.

Now there's always the possibility that the update to EPP will help with your issue as well, however if it doesn't then we'll have to get new debug information once the new version of EPP is released.

Share this post


Link to post
Share on other sites

Bah.

Deliberately provoking BSODs is a terrible idea.  It's one thing on a system that's already screwed to take a dump to try to get a problem resolved, but deliberately doing that is dangerous. Whereas it's true that file-system recovery seems a lot better these days than with, say XP, and full drive scans with chkdsk after reboot after BSODs haven't yet shown a problem... that's misleading.  Even with chkdsk saying the FS is ok, I have had corrupted files.  So far, as far as I know, these have only been "unimportant" files - that is they were important to me, but not to the OS's integrity. 

If I'm planning to try to recreate a problem I'll shut down everything I don't need to have running first.  But that also means the test environment is less realistic.  

For this specific problem - the machine hanging while trying to handle an alert notification - there must be an overall logic problem.  A race condition maybe?  EAM has fallen down this hole repeatedly over the last few years.  It gets fixed, and then it comes back.  I sincerely hope that someone will look for the underlying cause, rather than just a short-term fix.

Right now I'm trying to avoid using my script to do things that might trigger it - the huge irony being that there's no EAM issue if I manually navigate to the folder I want to look in ... it's just inconvenient (but not as inconvenient as a hang) having to do that.   And of course presumably the issue will occur if I get a BB alert for any other reason.

Share this post


Link to post
Share on other sites
20 hours ago, JeremyNicoll said:

Even with chkdsk saying the FS is ok, I have had corrupted files.

chkdsk is intended to repair the filesystem. Corrupted files can't be validated or repaired unless there are backup copies of them.

 

21 hours ago, JeremyNicoll said:

And of course presumably the issue will occur if I get a BB alert for any other reason.

From what I've been told about similar issues you've reported in the past, my understanding is that this probably won't be the case, and you'll more than likely only see the issue when using your scripts.

Share this post


Link to post
Share on other sites

> chkdsk is intended to repair the filesystem.

Yes, but if a chkdsk scan says that there is nothing that needs to be repaired then it won't try.

 

> Corrupted files can't be validated or repaired unless there are backup copies of them.

When I had this happen, the (as I thought) plain text notes file, when opened after reboot after a BSOD and apparently ok chkdsk, was revealed to contain only hex nulls.

That means the file system had recorded the theoretical existence of the file, its name etc, and a start location and size on disk... but the area concerned was presumably empty.  The application that creates those files (a text editor) does not pre-allocate the space and then write to it...    I had expected to see the data that had been in that file at the last point at which it was saved before the BSOD.   I am surprised that chkdsk did not think there was a problem.

 

> From what I've been told about similar issues you've reported in the past, my understanding is that this probably won't be the case, and you'll more than likely only see the issue when using your scripts.

Why?     Why would a BB alert for one of my scripts not be treated in the same way as a BB alert for a problem in any software?   

Share this post


Link to post
Share on other sites
13 hours ago, JeremyNicoll said:

I am surprised that chkdsk did not think there was a problem.

chkdsk doesn't look for problems with files. It's concern is primarily with the filesystem, as that has a greater effect on system stability.

 

13 hours ago, JeremyNicoll said:

When I had this happen, the (as I thought) plain text notes file, when opened after reboot after a BSOD and apparently ok chkdsk, was revealed to contain only hex nulls.

chkdsk probably had to restore filesystem data regarding the file (presumably data from the MFT) from the journal, which probably contained out of date data describing the location of the various parts of the file on the filesystem.

 

13 hours ago, JeremyNicoll said:

Why?     Why would a BB alert for one of my scripts not be treated in the same way as a BB alert for a problem in any software?

I don't think I was ever given specifics about why. What I do remember is something about your scripting system not operating like most programs (at least in regards to what it's doing when it triggers alerts), and that's why the issues you run into with it aren't seen by other EAM users.

Share this post


Link to post
Share on other sites

> chkdsk

I run it from each disk's Properties -> Tools option; it does a quick scan and then I /always/ tell it to do the more thorough check.  But if it then says the disk is fine, I don't tell it to fix anything.  So it should not be restoring data from anywhere.

 

> BB alerts

I don't get it.  Once my script has done or tried to do something that the BB thinks is iffy, it should be no different from any other program or script  ... or malware.   The BB should be displaying its opinion and doing whatever follow-on actions it always does.   It's EAM and the BB alert that's hanging, not my script (as shown by the mouse pointer becoming an egg-timer when it is over the BB alert pane, not before that, and the BB alert pane's display being incomplete - not offering options or being dismissable).

The script (in VBS) runs under wscript.exe, whose pid is known - it shows up on eg "pslist -t".  That wscript is running as a child process of something else can hardly be unusual for a script.

Share this post


Link to post
Share on other sites
17 hours ago, JeremyNicoll said:

The script (in VBS) runs under wscript.exe, whose pid is known - it shows up on eg "pslist -t".  That wscript is running as a child process of something else can hardly be unusual for a script.

My understanding is that there is something unique about your scripts, but it's been to long to remember what it was. Perhaps it was the way you launch them, or several scripts firing monitored events around the same time, but whatever it is it doesn't act like other programs do.

 

18 hours ago, JeremyNicoll said:

I don't get it.  Once my script has done or tried to do something that the BB thinks is iffy, it should be no different from any other program or script  ... or malware.   The BB should be displaying its opinion and doing whatever follow-on actions it always does.   It's EAM and the BB alert that's hanging, not my script (as shown by the mouse pointer becoming an egg-timer when it is over the BB alert pane, not before that, and the BB alert pane's display being incomplete - not offering options or being dismissable).

I'm not trying to tell you where the problem originates from, I'm just trying to explain why the issue shouldn't happen with anything other than your scripts.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.