Alan_S

Member
  • Content Count

    75
  • Joined

  • Last visited

Community Reputation

3 Neutral

About Alan_S

  • Rank
    Active Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Aha! Yes Marko, I did misunderstand. I haven't experienced any problems when altering the debug logging state. I'll leave it on though as it might give a bit more info for anyone who is working on the problem. Thanks for the clarification.
  2. So do I stapp. With a proper a mechanical switch too... To business: It's very early days but the good news is that I haven't experienced any freezes at start-up with build 9073, installed a week ago. The bad news is that I've experienced 3 freezes during normal activity: last Wednesday, Friday and Sunday. I've sent a dump for each of these to [email protected]emsisoft.com asking that it be forwarded to you, GT500. Also, a doc file for each, describing the scenarios. Were I a developer I'd want as much material as possible, but I leave it to you to decide what your people need. I really hope they can find out what's going on and fix it, as a freeze every other day is just not viable. Or perhaps the problem is that my two computers and EAM are simply not compatible. I'm going to try Marko's advice and have debug logging enabled continually. It does agree with my own experience when all this started (see my original post). But even if it works, I can't accept it as a solution. Just a very temporary workaround until the developers fix it properly. Fingers crossed...
  3. Alan_S

    UI problems

    I did a very simple and brief test, clicking Settings and then Advanced. a2guard is in action very little: now and then a brief flash of 1 - 4% but that's all. a2start uses CPU continually when in Settings: about 1 – 3%, most of the time exactly 1.92%. This is what I did: Start Win Launch UI but do nothing a2start 1.5 – 3% continually, mainly 1.92% a2guard zero 13:43 Click Settings a2start 1.5 – 3% continually, mainly 1.92% a2guard briefly 4% 13:45 Click Advanced – no response a2start 1.5 – 3% continually, mainly 1.92% a2guard zero 13:48 Click PX then EAM still no response a2start 1.5 – 3% continually, mainly 1.92% a2guard zero 13:49 Get reply a2start 1.5 – 3% continually, mainly 1.92% a2guard zero Close UI Then, a look at logs. Start Win Launch UI and do a Quick scan 14:15 Click Logs Hightlight the scan and click View Details No response a2start zero a2guard zero 14:18 Click the Process Explorer window then the UI window and the reply pop-up appears! The 'other' window doesn't have to be PX: Notepad, Windows Explorer - anything will do the trick. But look at the attached pop-up screenshot. Note that the reply pop-up is not complete: only what overlays the window behind it (Process Explorer here). The rest can be coaxed out of hiding by moving the window behind, to increase the 'shadow', in this case moving Process Explorer right. Well, it's a workaround but it can be tricky with a cluttered desktop. If the whole pop-up can't be retrieved there's another problem: it has to be closed before anything else can be done and how to do that when neither the Close button nor the 'X' in the top right hand corner are accessable? Two other observations: When waiting for a reply from 'View details' the UI window is dead to the user. Can't move it on the desktop and can't close it. It appears that the problems only occur when a new log entry is in the list, even if the 'View details' concerns an older entry. Once past the hurdle it seems to work normally, at least until next time Logs is invoked, even if there are no new entries. Sorry, I see that this is all a bit incoherent. But it's not easy to invoke and observe on one computer and at the same time document on another computer! But perhaps it's of use. The bottom line is that a2guard uses very little CPU and only briefly. a2start uses CPU continually when in Settings - almost all the time 1.92% but almost nothing when trying to look at logs, even when waiting for a reply that should be instantaneous.
  4. Marko, your comments regarding debug logs rang a bell but couldn't put my finger on it. Now I remember: Look at the very first post I made when I started this thread. I recall now that debug logging appeared to help back in June but I seem to remember that it wasn't a 100% cure - a bit hazy... But even so, I don't really feel that it's an acceptable solution.
  5. Thanks Marko. It might just be something to do with logging. I'll keep an eye on it. But in my case the problem only occurs at around 2-3 week intervals (at least it did...) but then a shower of several occurrences.
  6. Alan_S

    UI problems

    This occurs in 2018.11.0.9073 Debug logs sent via PM. Didn't occur with the previous stable build. When clicking something on the UI, the response is often really slow (perhaps minutes) or not at all. Sometimes it can respond with 'persuasion'. For example 'Settings' on the overview: The result can sometimes be coaxed forth by moving the UI window on the desktop, if this is possible (sometimes the UI gets locked and then a Windows restart is the only way out). Viewing log entries is particularly problematic. The following is a crude log of a session today, 2018-12-07, observed on my HP EliteBook 8440p, Windows 7 Pro 32-bit 09:40 Started Windows 09:42 Launched UI (clicked the icon in the notification area) 09:42 Clicked 'About' Nothing happened. 09:43 Moved the UI window on the desktop: Result of 'About' displays 09:44 Clicked 'Logs' Nothing happened. Moved the UI and the log list displays. But: the UI window is locked. Couldn't mark a log entry to view it Couldn't move the UI window on the desktop 09:47 Couldn't move the mouse cursor to the taskbar. Nor launch any of the desktop shortcuts. Since everything is dead, want to invoke BSOD via Right Ctrl / ScrLk / ScrLk on the USB keyboard Can't do: it's not plugged in. In desperation, plugged it in – immediately everything freed up! The result of 'About' is displayed. Launched Event Viewer. Nothing pertinent reported. 09:55 Restarted Windows 00:56 Ready 09:57 Launched UI (clicked icon in the notification area) Clicked 'About' Nothing happened. 09:59 Clicked 'About' again. Still nothing happened. Closed UI 10:00 Launched UI (clicked icon in the notification area) Clicked 'Logs' . It launched OK. with top entry highlighted Clicked 'View details' Sub-window launches, showing results of 'About', not of the top entry 10:02 Closed the sub-window 10:03 Highlighted another entry in the log list and clicked view details. Worked fine 10:05 Returned to the UI overview Clicked 'Update now' 10:06 Update done. 10:07 Clicked 'Logs' In the list, selected the update just done Clicked View Details. Nothing happened The UI window is locked. Can't move it on the desktop. Can't do anything. 10:10 Launched a program via its desktop shortcut The UI 'thaws', launching a sub-window showing not the results of the update, but of 10:07 10:13 Closed the UI Debug logs supplied cover the above. One more thing: When a sub-window has been 'persuaded' to pop up by clicking another window or launching a program, only a bit of it is displayed sometimes. This appears to be an area that is the outline of the other window or that of the program launched. Now, all this might just be something to do with my computers rather than a fault in EAM. If so, I'd be grateful for any tips.
  7. Thanks, I'll stash that away in the old grey matter!
  8. Well, it has happened, though not at start-up. This morning, I was using my EliteBook, which has the current stable version 2018.11.0.9073 (it was never switched to the beta feed), and around 10:40 CET decided it was time for a break. On returning, noted that the screen was black. First assumption was that it was in sleep but the power button was illuminated constantly, not blinking. Couldn't get any response so invoked a BSOD at about 11:08. On restarting, saw (as expected) that a2service.exe had bombed at 10:58:11. So, should I send the dump? Sadly, there are no debug logs. Ironically, the morning's work was documenting a UI problem and I had temporarily turned off debugging to be able to copy the logs after my break. I still have a dump taken when using 2018.11.0.9073 beta on my Dell stationary. It occurred (2018-12-05) when I set my printer preferences to 'duplex' to print a document. Would that be of any use, or can I delete it?
  9. Sorry, I missed your post of last Monday about the fix now being in the stable version. I switched to the beta version last Saturday. Anyway, the old problem surfaced today under the latest beta, 2018-11.09.2073, when preparing to print a document, setting the printer to duplex printing (I use Apache Open Office and an oldie but goodie Canon "MP730 SmartBase Photo" printer). Since the current fix is now stable, I'd prefer to return to the stable fold if that's OK with you. The problem with being in the beta community when trying to concentrate on a specific issue is that (obviously) other troubles tend to occur, thus muddying the waters.
  10. Alan_S

    NEW Build 9069

    I updated my stable EAM to the beta version yesterday and have noticed Marko's delays too. They vary: sometimes nothing, sometimes very noticeable. Also, I encounter serious delays with viewing details of a log entry, though sometimes the response is instantaneous. Example 2018-12-02 11:04 PC restarted Clicked 'Logs' Selected an entry and clicked View Details (Response Instantaneous) Closed the UI and reopened Clicked 'Logs' Selected an entry and clicked View Details (Response 2 mins 45 secs) Backed to 'Home' Clicked 'Logs' Selected an entry and clicked View Details (Response 45 secs) Backed to 'Home' Clicked 'Logs' Selected an entry and clicked View Details. View Details button turned blue and then back to white. Nothing happening Started Process Explorer. No CPU used by the a2.. processes. After a while closed PE and immediately got the details pop-up. Coincidence or related? Total response time 5 mins. Oh yes, later (sadly after disabling Debug Logging) clicked “About” got the result after about 25 secs. I've sent the debug logs via PM. Win 7 32-bit EAM version 2018.11.0.9069 updated 10:06:45 Sphinx Windows 10 Firewall Control Time zone CET
  11. Very, very good news! I'll keep an eye on the beta releases. Just one question: I assume I get the beta release by changing "Update feed" in the settings to "Beta" and then the Update will fix it, Right? But when the beta version is released as "Stable", how do I get back to that state? Simply set "Update feed" as stable or should I un-install the beta first? Santa Claus has come early...
  12. A problem concerning the 2 incidents on the EliteBook 2018-11-22. Next day, it was running but I had left it, to do some work on the Dell. Suddenly a BSOD on the EliteBook! Out of the blue. Hadn't touched it for some time. So, the dump file of 2018-11-22 got overwritten. I had already turned off debug logging and automatic updates, so at least updating can surely be exonerated? I think this is an interesting case - happening spontaneously. Then the Dell. I still have the material I mentioned last Wednesday: Dump, debug logs and EmsisoftDiagLog.txt I've sent both these and a PM.
  13. According to my notes, the last diagnostic material I sent was at the end of July. Speaking as an old programmer, I'm surprised that the developers are satisfied to be working (if they still are) with material from a version that is so old. But if it's OK with them then that's fine. My only interest is that the problem gets identified -- and I don't care whether it's EAM's “fault” or mine -- and zapped. Yes, there are some paths to epp-modules in the registry, but that would be natural since EAM has been re-installed after the uninstall. But I thought it was things like that that emsiclean was supposed to find. I can do a new uninstall exercise and check - if that would help. As for the problem always occurring on update, no - it updates every two hours and almost always at start-up. However, I suppose there could well be a timing issue where an update starts at a sensitive time (not just at start-up either). That would explain a lot. Diagnostic logs covering today's two incidents on the HP EliteBook are available as they are for yesterday's incident on the Dell. They might shed some light.
  14. Yes I did, following the instructions in https://helpdesk.emsisoft.com/en-us/article/150-how-do-i-completely-uninstall-an-emsisoft-product Thus after the uninstall I downloaded emsiclean.zip from the link provided there (actually, there was no choice since uninstall had removed it) Unpacked it and ran EmsiClean32.exe. It reported that uninstall had left C:\Program Files\Emsisoft Anti-Malware (with some content) but, as recommended, closed the program without letting it do anything. I then renamed the directory to C:\Program Files\Emsisoft Anti-Malware_Old rather than deleting directly. I ran regedit to see if anything was left. There were some 'Emsisoft items' but none that I felt had any bearing on the running of the program as such, so left them. Then, I downloaded EAM, installed it and entered my licence key. Before starting this exercise, I documented the settings and then exported them. My plan was/is to not import them but start from scratch. Of course, that means that EAM now needs interaction and an import would make life a lot easier. In the context of what I'm trying to achieve (a fresh installation in the hope of getting rid of the problem) could an import potentially mess up the good work? I also took an image copy of the system so if I've done anything wrong above (e.g. using a downloaded EmsiClean32.exe) I can re-do it all. The above took place on my Dell stationary computer. Today, at 13:20 CET I started up my HP EliteBook which hadn't been used for about a week. No prizes for guessing what happened... After a forced restart and doing what I wanted, I turned it off and then at 15:58 fired it up again. Noted that EAM started updating, the shield in the notification area being light green and pulsating, which suddenly stopped... Two incidents in a couple of hours! This (it occurring on both machines and several times within a very short time) has happened before. However far out it sounds, could there be some connection with the time? Finally, since you didn't ask for the material I have, I assume the developers don't need it. Right?
  15. This problem still occurs in version 2018.10.1.9026. Occurs at about 3-week intervals. In fact it occurred on start-up yesterday morning: after logon but before I had done anything at all. So it's nothing to do with launching any particular program. It's extremely irritating and a great time waster. Generally seems to occur when I'm in a hurry. If the developers are interested, I have a dump, diagnostic logs and an EmsisoftDiagLog.txt. One thing I have done today is a clean re-installation of EAM. I doubt it will help (it shouldn't) but it's worth a try.