JeremyNicoll

System hang after 'Suspicious activity box' could not be dismissed

Recommended Posts

EIS 2017.4.0.7424   W8.1  64bit

Within my text editor, Kedit, I issued a command (of a sort I run many times per day) which runs a script that runs within the editor environment.  The command was: fav progr

It (fav.kex - written in KEXX which is more or less REXX but built-in to Kedit) presents a list of a bunch of folders and files whose nicknames (set by me) match the parameter I gave and lets me open whichever one I wanted. On this occasion I chose C:\Program Data, and then  nothing happened.  The editor fav.kex script (which logged what it did) issued:

  winexec nowait normal wscript.exe "C:\Dropbox\JN_VB_and_VBS\JN-Shell-Explore-Folder.vbs" "full" "C:\ProgramData"

and that process (executing 'winexec') ran ok; the logs show that it received a zero return-code.

But I got an EIS pop-up telling me that the behaviour of that vbs program was doubted - which in itself is odd because that program is run many times per day & has not changed since May 2016.   The pop-up said:

   Suspicious behaviour has been found in the following program:

    C:\Dropbox\JN_VB_and_VBS\JN-Shell-Explore-Folder.vbs

    ? Verifying status with Anti-Malware Network...

                                                                                                          Cancel

Clicking 'Cancel' had no effect.  After maybe a minute or two, I got an OS message box:

   title: Emsisoft Real-Time Protection

   Emsisoft Real-Time Protection is not responding.

   If you close the program you might lose information.

   -> Close the program
   -> Wait for the program to respond

After clicking on the latter option a few times, which each time just returned me to the  'Suspicious behaviour' dialog, and after a while told me again that Emsi wasn't responding, I chose the 'Close the program' option.   The EIS systray icon then disappeared.  

I wasn't then absolutely sure if just the GUI had gone or more than that.

The 'Suspicious behaviour' thing had, it seemed, stopped explorer from opening a folder viewer, and when I next clicked on part of an explorer window, the whole desktop background vanished leaving a dark blue screen with a bronze stripe across the bottom of the screen (where the taskbar would be), with a grey box where the system clock display should be.

After a while, I got another message box: "Windows Explorer is not responding"...

Fortunately I had my text editor window open, so could create these notes, and also issue system commands.  I tried: "dosq explorer.exe" but that didn't seem to do anything.  

However "dosq cmd.exe" did give me a command window, and I was able to use (SysInernals') pslist, and in due course pskill to kill explorer.  However although I was able to start a new instance of explorer, that didn't bring back the desktop.

After saving my notes, I did manage to shutdown the system, by opening another cmd.exe window and issuing:    shutdown /s /t 0


After the reboot, looking in EIS' logs, I see that there was a successful update at 16:00, which is about half an hour before the freeze.  My own logs show the 'fav progr' command that provoked this was executed around 16:35 & had been preceded by several similar commands issued after 4pm.

I'm naturally curious why EIS picked on that instance of running the VBS program, but I'm much more concerned that clicking 'Cancel' on the 'Suspicious activity' message box did not give me control of the machine.  After all, I don't care what the Anti-Malware network might think of my program - I know it's doing what it is meant to do. 

Share this post


Link to post
Share on other sites

It's an unknown script being executed by wscript.exe, which is enough to seem suspicious. If the script does anything our Behavior Blocker would monitor for, then the Behavior Blocker would attempt to verify its safety with our Anti-Malware Network. If you want the script to always be allowed, then you should be able to add an Application Rule for it.

Share this post


Link to post
Share on other sites

Arthur, you've missed the point.

I was unable to wrest control from EIS when it got stuck trying to contact the Anti-malware network.   Possibly that happened at the start of running the VBS program, or maybe when that program asked windows to open the ProgramData folder, because when it hung, it crashed explorer.   Maybe that was caused by me telling Windows to end the unresponsive EIS task?   But why should EIS not have stopped holding me up?  Why wouldn't it take a click on its 'Cancel' button?  Whenever I moved the mouse over the 'suspicious behavior' pane, the pointer changed to a small blue (revolving?) circle.

And, if you're right that the BB thought the script was suspicious, why alert me then and not tens of times previously, every day, when the same script is run?  My logs show that happened 14 times yesterday.  The hanging instance was roughly in the middle of the 14 uses.

Share this post


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

I was unable to wrest control from EIS when it got stuck trying to contact the Anti-malware network.

I understand, however unless you can reproduce the issue then we won't be able to find out what is causing it. We'd probably need a complete memory dump from the system that shows the frozen processes so that we can get an idea of why it happened.

 

7 hours ago, JeremyNicoll said:

And, if you're right that the BB thought the script was suspicious, why alert me then and not tens of times previously, every day, when the same script is run?

We update the Behavior Blocker periodically, and can do so without a program update, so an update with changes to the Behavior Blocker detection rules is more than likely why the Behavior Blocker suddenly started trying to verify its safety.

Share this post


Link to post
Share on other sites

> I understand, however unless you can reproduce the issue then we won't be able to find out what is causing it. We'd probably need a

> complete memory dump from the system that shows the frozen processes so that we can get an idea of why it happened.

Is there an easy way to provoke the BB into doing an AMN lookup?  

I looked earlier today to see if there was any logging of the BB alert (no), or if the script had somehow got itself added to the application or BB rulesets (no,no). The sccript has run 33 times since the reboot after the hang, and I've not seen another BB alert.

 

> We update the Behavior Blocker periodically, and can do so without a program update, so an update with changes to the

> Behavior Blocker detection rules is more than likely why the Behavior Blocker suddenly started trying to verify its safety.

I did mention that there had been an uodate at 4pm.  Specifically:

   General Information:

   Update started: 10/05/2017 16:00:20
   Update ended: 10/05/2017 16:00:31
   Time elapsed: 0:00:11

   Update successful

   Detailed Information:

   28 modules, 11000910 bytes

   a2hosts.dat (1298 bytes) - updated
   a2trust.dat (397 bytes) - updated
   Signatures\BD\dalvik.ivd (4656 bytes) - updated
   Signatures\BD\e_spyw.i00 (1178 bytes) - updated
   Signatures\BD\e_spyw.i19 (95252 bytes) - updated
   Signatures\BD\e_spyw.i20 (214095 bytes) - updated
   Signatures\BD\e_spyw.i21 (310537 bytes) - updated
   Signatures\BD\e_spyw.i25 (330976 bytes) - updated
   Signatures\BD\e_spyw.i26 (370845 bytes) - updated
   Signatures\BD\emalware.000 (413411 bytes) - updated
   Signatures\BD\emalware.187 (72027 bytes) - updated
   Signatures\BD\emalware.212 (147059 bytes) - updated
   Signatures\BD\emalware.213 (174299 bytes) - updated
   Signatures\BD\emalware.216 (210113 bytes) - updated
   Signatures\BD\emalware.217 (223145 bytes) - updated
   Signatures\BD\emalware.i06 (689135 bytes) - updated
   Signatures\BD\emalware.i50 (554961 bytes) - updated
   Signatures\BD\emalware.i52 (559602 bytes) - updated
   Signatures\BD\emalware.i57 (629369 bytes) - updated
   Signatures\BD\emalware.i59 (580942 bytes) - updated
   Signatures\BD\emalware.i66 (613796 bytes) - updated
   Signatures\BD\emalware.i68 (566923 bytes) - updated
   Signatures\BD\emalware.i76 (672384 bytes) - updated
   Signatures\BD\emalware.i78 (584927 bytes) - updated
   Signatures\BD\java.cvd (2253750 bytes) - updated
   Signatures\BD\mdx_97.cvd (725188 bytes) - updated
   Signatures\BD\mdx_97.ivd (297 bytes) - updated
   Signatures\BD\update.txt (348 bytes) - updated


and my editor macro's log shows that I'd run the script just once before the hanging instance, but that scrpt started execution a few seconds after the EIS update was show to be complete:

20170509 15:56:24.550000 .
20170509 16:00:48.350000 under interprt=>KEXX<   args=>fav icons<
20170509 16:00:48.350000   src=>Windows COMMAND fav<   ver=>KEXX 5.62 14 Nov 2012<
20170509 16:00:48.400000 Now process 1 user arguments:
20170509 16:00:48.400000 1] arg: ICONS
20170509 16:00:48.400000    simple srch --> ix=0
20170509 16:00:48.400000    subset srch #matches: 1
20170509 16:00:48.400000    so ix=143 n=ICONS-FOR-SHORTCUTS t=DIRY p=C:\Dropbox\JN_Icons_for_shortcuts
20170509 16:00:48.400000    => queued vbsopenf cmd
20170509 16:00:48.400000 Now execute 1 queued commands:
20170509 16:00:48.400000 1] issuing: winexec nowait normal wscript.exe "C:\Dropbox\JN_VB_and_VBS\JN-Shell-Explore-Folder.vbs" "full" "C:\Dropbox\JN_Icons_for_shortcuts"
20170509 16:00:48.410000    rc: 0
20170509 16:00:48.410000 KEXX processing times: start->nicknames defined: 0.030000
20170509 16:00:48.410000 KEXX processing times: start->after file checks: 0.050000
20170509 16:00:48.410000 ending; began: 20170509 16:00:48.350000, logstart: 20170509 16:00:48.350000.
20170509 16:00:48.410000 .
20170509 16:35:13.570000 under interprt=>KEXX<   args=>fav progr<

As that shows, the script log (although it's written as the script is ending, the lines in it are timestamped according to what the script is doing as it does it) started execution at: 20170509 16:00:48.350000, which is 17 seconds after your update process says it was complete... unless that latter 'complete' is only for the fetch?

 

Edited by JeremyNicoll
c/nn times/33 times/

Share this post


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

Is there an easy way to provoke the BB into doing an AMN lookup?

A batch file that uses BatchGotAdmin will usually trigger a BB alert, and thus an AMN lookup will be done before displaying the alert. This is probably the easiest way, since small edits to the batch file will invalidate any AMN rules for it by changing its hash, and of course you can also delete a local Application Rule for it (if one was created).

 

22 hours ago, JeremyNicoll said:

and my editor macro's log shows that I'd run the script just once before the hanging instance, but that scrpt started execution a few seconds after the EIS update was show to be complete:

...

As that shows, the script log (although it's written as the script is ending, the lines in it are timestamped according to what the script is doing as it does it) started execution at: 20170509 16:00:48.350000, which is 17 seconds after your update process says it was complete... unless that latter 'complete' is only for the fetch?

Updates being installed while there was an AMN lookup could have certainly caused a freeze, since update installation is very CPU intensive. Usually that freeze only lasts for a few seconds, however if there's a lot of files to update then that freeze can certainly seem like it takes longer.

Share this post


Link to post
Share on other sites

> A batch file that uses BatchGotAdmin will usually trigger a BB alert ...

OK. I'll try to find time to see if I can provoke a recurrence.  Although it wasn't the cause then, what happens if one is offline when an AMN lookup might be attempted?  Does the BB recognise that and just not bother - and if so, does the suspiciou sactivity just get blocked?  On the other hand, if - say - I provoke an AMN lookup then switch off the laptop's wifi, would you expect the AMN lookup process to handle that cleanly? 

> Updates being installed while there was an AMN lookup could have certainly caused a freeze ...

Yes but they weren't being.  Your log shows the update process was complete 17 seconds before the editor macro attempted to run the VBS script.

> Usually that freeze only lasts for a few seconds, however if there's a lot of files to update then that freeze can certainly seem like it takes longer.

It wasn't just a few seconds.  It was about 15 minutes before I finished investigating and (looked up notes on eg the shutdown command) and decided to try it to shut down the machine.  I was VERY lucky that the text editor, with its command-issuing potential, was still running because when explorer took away the desktop there was no way for me to find my way to other tools. 

Share this post


Link to post
Share on other sites
On 5/11/2017 at 3:55 PM, JeremyNicoll said:

what happens if one is offline when an AMN lookup might be attempted?

If a connection to our servers for an AMN lookup fails, then the BB will display an alert.

 

On 5/11/2017 at 3:55 PM, JeremyNicoll said:

if - say - I provoke an AMN lookup then switch off the laptop's wifi, would you expect the AMN lookup process to handle that cleanly

I would expect an "Internal processing error" to be displayed, although that could depend on where it was in the process of communicating with our servers when the WiFi was turned off.

 

On 5/11/2017 at 3:55 PM, JeremyNicoll said:

I was VERY lucky that the text editor, with its command-issuing potential, was still running because when explorer took away the desktop there was no way for me to find my way to other tools.

The Task Manager wouldn't open using the Ctrl+Shift+Esc shortcut?

Share this post


Link to post
Share on other sites

> The Task Manager wouldn't open using the Ctrl+Shift+Esc shortcut?

Dunno.  Didn't try it - not familiar with the shortcut - usually start TM from right-click on taskbar, if I need it.   But that's rare because I have Process Hacker running... but obviously didn't look at that because there was no desktop.  Just a dark blue screen, with thank-goodness, my text editor window still alive.  I don't know why that /was/ accessible, unless it's just that it was the only non-minimised application running at the time.

Share this post


Link to post
Share on other sites

Sometimes Alt-Tab still works in cases like that as well, however that depends on what exactly is frozen.

Share this post


Link to post
Share on other sites

Using W8.1, 64bit, EIS 2017.5.1.7567, Stable feed.

This problem happened again today.  Same reason -  running the 'fav' script inside Kedit, which then launches a VBS script to use

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

to open a File Explorer view of a folder.  Just like last time EIS popped up a 'suspicious behaviour' alert, which couldn't be cancelled and never reached a decision.   I was writing notes in my text editor at the time, and could still Save those notes, but when eg I made a screenshot of the alert pane, started IrfanView and pasted that in, when I tried a SaveAs I just got a revolving blue circle and IrfanView's window title changed to 'Not Responding'.  I started a second instance of the text editor and tried to SaveAs from there, and also got the blue circle.

Double-clicking my desktop shortcut to 'Admin Tools' (to go and look at EventViewer) produced no action at all.

The EIS alert pane showed the same revolving blue circle whenever the mouse pointer was over it.  If I clicked anywhere on the pane it was replaced by an OS 'not responding' box, offering me the choice of waiting until it did respond (which never happened) or terminating EIS - which I didn't want to do.

I was however able to sign-out.

I signed-in again, and turned debug logging on.  Then from another Kedit session, issued fav prog (to get a list of 'prog' files and folders) and chose program-data (again).  The macro told me it had issued the command to run the VBS script.  But nothing at all then happened - no folder view opened, no alert pane was displayed.  Double-clicking 'AdminTools' again did nothing.  I took a screenshot of my edit session and was able to paste that into a new instance of IrfanView, but as before its File -> SaveAs just gave the blue spinner.  IrfanView's window title again said 'Not responding'.  I also tried double-clicking the desktop 'RecycleBin' shortcut - nothing happened.

I signed-out again.

I'll PM the debug logs to you.   For the avoidance of doubt, it's not the fact that I get an alert (at least when debug logging isn't on) that bothers me, but instead the fact that the alert pane isn't cancellable etc.

(logs sent)

 

Share this post


Link to post
Share on other sites

There's only one EventLog record that's relevant, and I'm not sure that it sheds any light:

Log Name:      Application
Source:        Application Hang
Date:          12/06/2017 07:42:35
Event ID:      1002
Task Category: (101)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      SAMSUNG-NP350
Description:
The program a2guard.exe version 2017.5.1.7567 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Action Center control panel.
 Process ID: 18e0
 Start Time: 01d2e340dbe9620c
 Termination Time: 4294967295
 Application Path: C:\Program Files\Emsisoft Internet Security\a2guard.exe
 Report Id: 0a10cbd3-4f39-11e7-809b-50b7c3e8a12a
 Faulting package full name:
 Faulting package-relative application ID:

Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Hang" />
    <EventID Qualifiers="0">1002</EventID>
    <Level>2</Level>
    <Task>101</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2017-06-12T06:42:35.000000000Z" />
    <EventRecordID>142591</EventRecordID>
    <Channel>Application</Channel>
    <Computer>SAMSUNG-NP350</Computer>
    <Security />
  </System>
  <EventData>
    <Data>a2guard.exe</Data>
    <Data>2017.5.1.7567</Data>
    <Data>18e0</Data>
    <Data>01d2e340dbe9620c</Data>
    <Data>4294967295</Data>
    <Data>C:\Program Files\Emsisoft Internet Security\a2guard.exe</Data>
    <Data>0a10cbd3-4f39-11e7-809b-50b7c3e8a12a</Data>
    <Data>
    </Data>
    <Data>
    </Data>
    <Binary>55006E006B006E006F0077006E0000000000</Binary>
  </EventData>
</Event>

Share this post


Link to post
Share on other sites

I'll go ahead and pass on your debug logs.

If you happen to experience this again, note that when it comes to system freezes it's often best to have a full memory dump from the system to analyze. On most versions of Windows this method of creating a controlled BSoD will allow you to get that memory dump (assuming you don't already have it turned on).

Share this post


Link to post
Share on other sites

Unfortunately the Bellavista method is no use to me as I have no ScrollLock key on
this laptop.  I did it the hard way instead, setting up an alternate trigger, then
tested that that would create a full dump on request.

(I'm not sure that I'd agree wth Orlando Pivi's assertion that a 'controlled blue
screen is safe', though.  By its nature this surely risks damage to a file system?
- but needs must.)

Anyway, after I'd tested the dump process and done a clean shutdown & reboot, I
edited the VBS script concerned (to change its hash, as you suggested), then opened
a different editor window and issued the same command sequence as before.

That's to say: my text editor KEDIT, ie:
    C:\Program Files (x86)\~M-folder\Mansfield\KeditV161\KEDITW32.exe

ran a 'KEXX' macro, which in turn issued a command to run a VBS script:
    C:\Dropbox\JN_VB_and_VBS\JN-Shell-Explore-Folder.vbs

The command the macro issued, to run the VBS script, was:

   winexec nowait normal wscript.exe "C:\Dropbox\JN_VB_and_VBS\JN-Shell-Explore-Folder.vbs" "full" "C:\ProgramData"


The reason for the "full" parameter before the full path of the target folder is
that this script also takes some requests in terms of ShellSpecialFolderConstants
as described at:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb774096(v=vs.85).aspx

The script parses the (in this case) specified full path into a variable named
'pathspnm' and then executes:

   set FSO = CreateObject("Scripting.FileSystemObject")
   fexists = FSO.FolderExists(pathspnm)
   set FSO = Nothing

   if not fexists then
      grumble = "FULL did not find 'fullpath' folder: >" & pathspnm & "<" & nl2
      wscript.echo msgfrm & grumble & callas
      wscript.quit
   end if

   usefoldr = pathspnm

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


As before, an AMN pane slid in from the righthandside of the screen, and as soon as
I put the mouse pointer over that pane it displayed as a spinning blue circle.  I
triggered the system dump immediately.

I'll PM you with the location of the zipped-up dump.

Share this post


Link to post
Share on other sites

Would it be possible to get another memory dump? There was an issue with the dump that prevented a readable stack trace from being generated. If we can get another memory dump that doesn't have that issue, then we might be able to figure out what's going on sooner. Otherwise we'll need to get debug logs, and it will take longer to get those looked at.

Either way, it sounds like the problem will take some time to fix, so the difference is essentially just in the amount of time it takes for me to get an explanation of what is happening.

Share this post


Link to post
Share on other sites

Would turning on debug logging before trying to recreate this be useful?  And... would it work?   Are the logs flushed to disk often enough that there would be enough relevant info in them after I reboot after dumping the system (or if not flushed would you be able to find as-yet unwritten log records in buffers somewhere in the dump)?

Also, is there anything that I can do to influence whatever the "issue with the dump" was?

Share this post


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

Would turning on debug logging before trying to recreate this be useful?  And... would it work?

More than likely yes. Since there is a hang we can't be 100% certain the event will be logged completely, however another dump has the same issue as the first then debug logs would be our only way to tell what is going on.

 

21 hours ago, JeremyNicoll said:

Are the logs flushed to disk often enough that there would be enough relevant info in them after I reboot after dumping the system (or if not flushed would you be able to find as-yet unwritten log records in buffers somewhere in the dump)?

They should be written to disk quickly enough, at least in most cases. It just depends on how quickly the hang started to interfere with saving the logs (or if it interferes with it at all).

 

21 hours ago, JeremyNicoll said:

Also, is there anything that I can do to influence whatever the "issue with the dump" was?

I don't think so. From what I was told, it sounds like there was no indication as to why the issue had occurred, and without knowing what caused it we could only speculate as to whether or not you could prevent it.

Share this post


Link to post
Share on other sites

Trying again.  I logged-in to my administrator id (which is where I'm nearly certain I was logged-in when I first had the 'hang', and it's certainly the userid I was using when I forced the first full dump.

I edited the VBS script to change its comments, and hence its hash.

I turned on EIS debug logging and rebooted.

Once logged-in again, I deleted a few files from TEMP & the Recycle Bin, checked that debug logging was occurring, updated these notes - so therefore had a Kedit session active, saved the notes, then issued from Kedit: 'fav prog', and as before chose C:\ProgramData from the list of offered locations.

As before, a 'Suspicious Behaviour' alert pane slid in from the right.  When I moved the mouse pointer over it I again just got a revolving blue circle. I waited maybe 10 seconds then forced the BSOD.

I'll PM the locations of the dump (which, compressed, is more than 100 MB larger this time so maybe it will contain you need) and the debug logs to you.

Share this post


Link to post
Share on other sites

Thanks. The data is on its way to one of our developers, and he'll take a look at it as soon as he can. ;)

Share this post


Link to post
Share on other sites

It looks like it may be an issue with a2guard.exe, however it's a little early to tell. The team that maintains a2guard.exe will have to look in to it, and that may take some time.

Share this post


Link to post
Share on other sites

I have tried this again.  The immediate problem might be fixed - I'm not sure yet - but what I did resulted in a hang elsewhere in EIS and I ended up taking another full system dump.  Frank already knows.

For anyone who is interested, what I did and what happened was:

From my normal day-to-day userid I switched to the Beta feed, did an update, did the required application restart, noted I'm now using version 2017.8.0.7904, then did a full shutdown and reboot.

I logged in after that as my admin id (where fewer programs are started automatically, and also it's where I have previously dumped the whole system when required).

Then I turned on debug logs, changed the VBS file (so its hash would be different from last time), and did another full shutdown and reboot.

Again I logged-in as my admin id.  I checked that debug logs had been created with the appropriate timestamp, checked my notes elsewhere about how to force a BSOD (and what I normally do afterwards), then saved these notes, so therefore had a Kedit session active.  As on previous occasions I issued from Kedit: 'fav prog', and as before chose "C:\ProgramData" from
the list of offered locations.

This time, a 'Suspicious Behaviour' alert pane slid in from the right, but it slid out again a few seconds later to be replaced by a BB alert box. So far so good.   But then I clicked on the 'More Info' down arrow on the alert box.   The text area expanded (I think) but then sort of greyed-out.  The bright red bit at the top of the box got paler, a sort of pink colour, and under that the whole of the rest of the text area was just white with no information on it.

As soon as I moused over that I got the spinning blue circle, and an OS warning that something wasn't responding.  I did manage to take a screenshot of the useless info box, started IrfanView ok, pasted the screenshot in, but as soon as I did a File -> SaveAs, Irfanview also got a blue spinning circle and an OS 'not responding' info box.

I forced a BSOD.  Rebooting after that I've now got at least one corrupted file - the place where I was writing detailed notes of what I was doing is now just a file of x'00's.  Chkdsk says both disks are ok, but one has to wonder a bit.

I did have debug logging on while doing all this, but - not surprisingly - those files are empty.  I know that flushing them to disk often would slow them down a lot, and I suppose if a BSOD is going to mean the file system meta data doesn't get written cleanly back to disk then there's not much one can do about that, but it's a nuisance.

As soon as I noticed this I made a separate set of notes of what I could remember of what I'd done, not so detailed though.

I'll compress the dump and send you a link in the next few minutes.

The forensic log does show two entries before the point where the BSOD was done:

  25/08/2017 11:14:20
  A notification message "Suspicious behavior has been found in the following program: C:\Dropbox\JN_VB_and_VBS\JN-Shell-Explore-Folder.vbs" has been shown

and shortly after that for the BB alert panel:

  25/08/2017 11:14:23
  Alert message "C:\Dropbox\JN_VB_and_VBS\JN-Shell-Explore-Folder.vbs  Program is attempting to modify your documents in a suspicious manner" has been shown

The next entry in that log is following the reboot after the BSOD.


Frank has asked that I try again, but not click on 'More Info'.

Share this post


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

Frank already knows.

I assume he has the memory dump as well?

Share this post


Link to post
Share on other sites

To retry the issue, without clicking 'More Info', this time I did this:

I started on my day-to-day userid, and checked that I still have the Beta in use.  Then I changed the VBS file (so its hash would be different again from last time, turned on debug logging, and did a full shutdown and reboot.

After that I logged-in as my admin id.

I started to edit a test file (on a secondary disk, where the files matter less) then issued 'fav prog' as usual and selected "C:\ProgramData" as before.

When the BB alert came up, I first tried answering 'Allow Once'... and the VBS application went ahead and opened the "C:\ProgramData" explorer view ok.

I then issues 'fav prog' again, & as hoped for got the BB alert again.  This time I tried 'Allow always', & the view opened again.  I then looked in my 'Application Rules' and had indeed gained a rule allowing this behaviour.

So, yes, the immediate problem IS fixed.


But the hang found earlier when using the 'More Info' button clearly needs attention, and I did find something else that I'll describe to Frank.  I'll send the debug logs to him for this latter issue.

Share this post


Link to post
Share on other sites
On 8/26/2017 at 7:25 AM, JeremyNicoll said:

> I assume he has the memory dump as well?        Yes. 

OK, good. If Frank has the debug information, then he'll add it to any relevant bug reports. ;)

 

On 8/26/2017 at 5:05 PM, JeremyNicoll said:

So, yes, the immediate problem IS fixed.

I'm glad to hear that. Hopefully it won't take too long for our developers to figure out why the issue is now happening when clicking "More info" as well.

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.