JeremyNicoll

Member
  • Content Count

    1840
  • Joined

  • Last visited

  • Days Won

    29

Everything posted by JeremyNicoll

  1. I thought I should update you on the monitoring of memory use that I've been doing in the last couple of weeks. First, on 3rd May I updated to V11.7.0.6394. In the following few days I didn't use the machine very much, but also noticed what appeared to be less of a memory problem; usage still climbed, but not so fast. The Process-Hacker-reported private bytes value for a2service climbed from around 500 MB when a2service first started, to about 1 GB, and then seemed to stabilise there for around a day and a half. After that I had to do another restart when I uninstalled something, and in the course of the next 24hr period a2service's private bytes went again from about 500 MB to 1 GB, then very fast shot up to 2.1 GB. In that period I'd done some quite heavy browsing - but there was no sign of memory use being attributed to Firefox, but it does make we wonder if certain types of website/webtraffic could make a2service 'work harder'? (Flash is disabled in my Firefox, so it can't be that.) Since then I've tried to keep an eye on memory use to see if there's an obvious relationship between what I'm doing, and rate of climb. I've not spotted anything. On Saturday 14th, it crossed my mind that it would be ironic if some interaction between Process Hacker (which I've just updated from an older version to the current one) and EIS could somehow cause EIS to grab memory & not release it... so after checking that the new PH works, I removed its startup from my user-login process and rebooted. Since then I've been using Task Manager only to monitor memory use... and the problem is still with me. Since that reboot, a2service's "commit size" (which is the same figure as PH's 'private bytes') started off at 497,452 KB and has climbed to 1,239,620 KB. I have also started running Sysinternals' "pslist -m" whenever the whim takes me, sending its output to a date/time-stamped file, and keeping those. The figures there do match those that I see in TM.
  2. Has anyone looked at the logs yet? Do they in fact trace memory being allocated and freed? I did take a quick peek at them before sending and didn't see any functions with the sorts of names (involving "mem", or "storage" or "free" etc) that looked as if they might be relevant. Of course I don't know what your functions would be named...
  3. I've no idea whether EIS should block access via a VPN. What I've written below is just a guess. When you try to access such a site directly from your own machine EIS must see that you're trying to make a connection to that iffy website. But when you use a VPN, it's the VPN server elsewhere in the world that would make that connection, and EIS isn't running on the VPN server. It seems to me that for EIS to detect that you are asking a VPN server to contact an iffy site, EIS would need to examine all the traffic between your computer and the VPN server, to read the contents of that traffic, not just test where it was being sent. I don't know if EIS does any checking of packet contents for any sort of traffic. Moreover, I would have thought that communication with a VPN server would be done over https rather than http? And if so wouldn't that mean that EIS would only see the encrypted contents of the traffic, not the plain text? How could it reach any conclusion then?
  4. > I don't see anything wrong with your config file ... You've passed the files to whoever's looking at the debug logs, though? > Drivers and services have options related to how they run. Those options are set when > they are registered. Usually they can be changed later on, but some changes can be > locked out (at least in the services manager). Have your developers ever seen instances of EIS drivers/services losing their original setup, (on systems without active malware)? I'd have thought that would be the kind of thing that 'self-protection' would try to inhibit, and at the very least, identify if it had happened.
  5. > Fresh configuration files, log files, re-registering the service and drivers, etc. The > Factory Defaults button doesn't reset everything, and the only way to get the original > config files back is to do a fresh install. I sent you a copy of all the comfig files in use, on 21st April. If there was a problem in them wouldn't you have told me by now? I have a problem believing that log files (ie the SQLite database) could have anything in it causing such a growing memory use. Is there more to registering services/drivers etc than a binary "it's registered or it isn't" situation? I mean, to the point that the product would run and appear to do everything it's meant to, but still have a creeping memory problem? Surely it's down to how the app requests memory from the OS, and when it releases it?
  6. New logs are created though (on W8.1) if you turn logging off & then on again, so provided that continues to be the case an automation solution will achieve what I want.
  7. > I've been working with computers since before IBM introduced the PC, Me too, and for much of that time as an MVS (ie z/OS these days) systems programmer. My view on "reinstall the app to fix a problem" would be "raise a ticket because something in the vendor's app-update process corrupts the app". > ... Now test and see if the problem persists. If it does now you can be sure it's EIS Are you suggesting that when Task Manager and Process Hacker both attribute a climbing 'Private Bytes' value to EIS, that somehow they have made a mistake? If we don't trust the OS's own tracking of memory, should I also reinstall Windows?
  8. > This must be an isolated issue.... most people reporting major issues... Apparently. Unless vast numbers of your users reboot frequently, or have had the problem but don't realise it. > Have we tried a fresh install to see if that has any effect on the issue? Why should it? What's different about a fresh install compared with one that's been updated by your released updates?
  9. > Debug logs will eat up gigabytes of disk space rather quickly. Yes, of course. Last time I ran with logging on for several days I was disappointed to see that there was no automatic close/reopen (spin-off) of the logs, which would make it easier to archive them (and throw-away older logs) automatically. Is there any point in asking for such a feature? If there is, please don't make the spin-off happen at any exact hour boundary, and definitely not midnight, since there's so many things on a computer that change/happen on such boundaries, and it'd be sad if logging was never active at such critical times! Ideally I'd rather see such a thing implemented by an external command, so anyone who wanted to do it could send a 'spin' command at times of their choosing. In the absence of such a feature, I will pick a screen automation utility (I've used none for real for many years) and try to write a script that will open the EIS support window, turn off logging for a second or so, and then turn it back on. Then I can adapt existing code (for other apps' logs) to archive the logs and delete older ones on a sensible basis.
  10. OK, I'm going to stop pursuing this matter for now. It does seem that there are several changes made to some .ini files separate from the arrival of new signatures, and while they might not tell me precisely what I want to know, they will provide clues if & when I hit this problem again. Moreover, once the creeping memory issue is solved, I intend to run with debug logging on all the time. My machine seems to have enough 'grunt' to be able to cope with that alright, and so hopefully there'll be much more info available in future.
  11. Peter: I'm lucky enough to have 8 GB of RAM in this machine, and therefore the machine can run for a few days without that. If I had only, say 2 GB, I would struggle to get one day's use. Surely that's not reasonable these days. Moreover, this memory problem started abruptly when EIS got updated a few weeks ago. Before that, no problem. It's not /self-/inflicted. If I were running any sort of server I would be appalled at the idea that a machine might need rebooted as frequently as you suggest.
  12. OK. In the last few days I've been using the machine less heavily than last week, however one thing I have done is install all of last month's Windows Updates, which I'd put off doing knowing that I'd very likely have to reboot while doing that. Memory use is still climbing though.
  13. I understand the purpose of threading (and pre-emptive scheduling) perfectly thanks. I was just asking if you'd expect to see quite so many threads. For all I know, there might be a problem with threads that should have ended, and released their acquired memory, not doing so. Is there any progress from whoever's been looking at the debug logs I sent?
  14. > If no files have been modified, then no update process has started Is there a file that should be modified before the update process makes any contact with your update servers? That is, before any external part of the process has a chance to stop an update from working? > A log can be started and then appended. Does that actually happen during an update process? If so, why have I never seen a 'we started but didn't finish' log record? > ... debug logs. Since you weren't able to collect them ... Are you saying the lack of debug logs is my fault?
  15. I just noticed something else, which might be a clue - I've no idea. Sysinternals' pslist shows nearly 160 threads in a2service (I can see that might be normal if many of them represent hooks in other processes, but if not, it seems an awful lot), and far far fewer in a2guard and a2start. C:\>pslist -x a2 pslist v1.3 - Sysinternals PsList Copyright © 2000-2012 Mark Russinovich Sysinternals - www.sysinternals.com Process and thread information for SAMSUNG-NP350: Name Pid VM WS Priv Priv Pk Faults NonP Page a2service 1176 1793944 10348 971332 1016940 7380062 86 286 Tid Pri Cswtch State User Time Kernel Time Elapsed Time 1180 10 1183 Wait:UserReq 0:00:02.687 0:00:00.546 6:59:14.175 1296 14 650 Wait:UserReq 0:00:00.031 0:00:00.015 6:59:13.550 1300 9 2627 Wait:UserReq 0:00:00.046 0:00:00.031 6:59:13.550 1304 8 25523 Wait:DelayExec 0:00:00.000 0:00:00.000 6:59:13.550 1308 8 1 Wait:UserReq 0:00:00.000 0:00:00.000 6:59:13.535 1312 10 2240052 Wait:UserReq 0:00:00.000 0:00:00.000 6:59:13.504 1316 8 2239472 Wait:UserReq 0:00:00.000 0:00:00.000 6:59:13.504 1320 9 34427 Wait:UserReq 0:00:00.031 0:00:00.031 6:59:13.363 1324 9 2070425 Wait:DelayExec 0:00:00.031 0:00:00.015 6:59:13.363 1328 9 8 Wait:UserReq 0:00:00.000 0:00:00.000 6:59:13.363 1336 8 3 Wait:UserReq 0:00:00.000 0:00:00.000 6:59:13.363 1340 10 1244 Wait:UserReq 0:00:00.546 0:00:00.453 6:59:13.363 1344 8 244279 Wait:DelayExec 0:00:00.000 0:00:00.000 6:59:13.363 1356 8 782 Wait:UserReq 0:00:00.000 0:00:00.000 6:59:13.003 1408 9 3 Wait:UserReq 0:00:00.000 0:00:00.000 6:59:12.957 1412 1 461 Wait:UserReq 0:00:00.000 0:00:00.312 6:59:12.957 1436 9 131616 Wait:UserReq 0:00:00.625 0:00:00.109 6:59:12.332 1440 9 185999 Wait:UserReq 0:00:00.859 0:00:00.156 6:59:12.332 1444 9 10151 Wait:UserReq 0:00:00.046 0:00:00.015 6:59:12.332 1448 8 1 Wait:Queue 0:00:00.000 0:00:00.000 6:59:12.300 1452 8 13834 Wait:UserReq 0:00:00.031 0:00:00.140 6:59:11.877 1460 9 2724 Wait:UserReq 0:00:04.796 0:00:00.187 6:59:11.877 1468 8 1 Wait:UserReq 0:00:00.000 0:00:00.000 6:59:11.877 1472 10 25 Wait:UserReq 0:00:00.000 0:00:00.000 6:59:11.877 1476 10 75543 Wait:UserReq 0:00:00.000 0:00:00.000 6:59:11.877 1504 9 2936 Wait:UserReq 0:00:04.609 0:00:00.140 6:59:11.862 1824 8 50557 Wait:UserReq 0:00:00.000 0:00:00.000 6:59:09.625 2352 9 2947 Wait:UserReq 0:00:04.468 0:00:00.093 6:59:07.909 3696 8 12 Wait:UserReq 0:00:00.000 0:00:00.000 6:59:00.167 3700 8 3 Wait:Queue 0:00:00.000 0:00:00.000 6:59:00.167 3704 8 1550 Wait:Queue 0:00:01.296 0:00:00.125 6:59:00.167 3708 8 1157 Wait:Queue 0:00:00.812 0:00:00.015 6:59:00.167 3712 9 23 Wait:Queue 0:00:00.000 0:00:00.000 6:59:00.167 3716 9 31 Wait:Queue 0:00:00.000 0:00:00.000 6:59:00.167 3720 9 49 Wait:Queue 0:00:00.015 0:00:00.000 6:59:00.167 3724 8 2548 Wait:Queue 0:00:01.718 0:00:00.203 6:59:00.167 3728 8 520 Wait:Queue 0:00:00.375 0:00:00.015 6:59:00.167 3732 9 14121 Wait:Queue 0:00:04.546 0:00:01.234 6:59:00.167 3736 9 18 Wait:Queue 0:00:00.000 0:00:00.000 6:59:00.167 3744 9 9 Wait:UserReq 0:00:00.000 0:00:00.000 6:59:00.167 3748 8 3 Wait:Queue 0:00:00.000 0:00:00.000 6:59:00.167 3752 8 1 Wait:Queue 0:00:00.000 0:00:00.000 6:59:00.167 3756 8 1 Wait:Queue 0:00:00.000 0:00:00.000 6:59:00.167 3764 8 1 Wait:Queue 0:00:00.000 0:00:00.000 6:59:00.167 3768 8 1 Wait:Queue 0:00:00.000 0:00:00.000 6:59:00.167 3772 8 1 Wait:Queue 0:00:00.000 0:00:00.000 6:59:00.167 3776 8 1 Wait:Queue 0:00:00.000 0:00:00.000 6:59:00.167 3780 8 2 Wait:Queue 0:00:00.000 0:00:00.000 6:59:00.167 3784 8 342 Wait:Queue 0:00:00.000 0:00:00.015 6:59:00.167 3788 9 1337 Wait:Queue 0:00:00.015 0:00:00.078 6:59:00.167 3792 10 15926 Wait:UserReq 0:00:00.312 0:00:00.781 6:59:00.167 4164 8 4 Wait:UserReq 0:00:00.000 0:00:00.000 6:58:54.610 4172 10 6912 Wait:UserReq 0:00:00.031 0:00:00.015 6:58:54.579 4192 8 1 Wait:UserReq 0:00:00.000 0:00:00.000 6:58:54.286 4212 9 912 Wait:UserReq 0:00:00.000 0:00:00.000 6:58:53.770 4216 8 863 Wait:UserReq 0:00:00.000 0:00:00.000 6:58:53.770 5468 10 20074 Wait:UserReq 0:00:01.984 0:00:00.703 6:58:33.048 244 9 3178 Wait:UserReq 0:00:04.203 0:00:00.125 6:57:09.445 2976 9 2814 Wait:UserReq 0:00:04.078 0:00:00.093 6:57:09.445 2852 9 2470 Wait:UserReq 0:00:03.906 0:00:00.109 6:57:09.445 4060 9 2260 Wait:UserReq 0:00:03.718 0:00:00.093 6:56:58.667 2760 9 2413 Wait:UserReq 0:00:03.562 0:00:00.125 6:56:58.664 3028 8 3 Wait:UserReq 0:00:00.000 0:00:00.000 6:52:44.120 3524 8 2 Wait:UserReq 0:00:00.000 0:00:00.000 6:52:41.500 4568 8 1 Wait:UserReq 0:00:00.000 0:00:00.000 6:52:41.473 4888 8 1 Wait:UserReq 0:00:00.000 0:00:00.000 6:52:41.447 1880 8 1 Wait:UserReq 0:00:00.000 0:00:00.000 6:52:41.421 776 9 2060 Wait:UserReq 0:00:02.281 0:00:00.125 6:23:21.828 3976 9 1887 Wait:UserReq 0:00:02.312 0:00:00.046 6:23:21.826 5792 9 2035 Wait:UserReq 0:00:02.125 0:00:00.015 6:17:09.031 1704 9 1625 Wait:UserReq 0:00:01.906 0:00:00.031 6:00:35.519 5612 9 1781 Wait:UserReq 0:00:01.937 0:00:00.046 6:00:35.271 1772 9 1900 Wait:UserReq 0:00:01.890 0:00:00.046 6:00:35.266 5532 9 1587 Wait:UserReq 0:00:02.015 0:00:00.031 6:00:35.264 2676 9 2111 Wait:UserReq 0:00:02.140 0:00:00.031 6:00:35.263 3216 9 1633 Wait:UserReq 0:00:01.812 0:00:00.015 6:00:35.240 4268 9 1658 Wait:UserReq 0:00:01.734 0:00:00.015 6:00:33.103 124 10 1953 Wait:UserReq 0:00:01.890 0:00:00.062 6:00:33.101 1924 9 1618 Wait:UserReq 0:00:01.453 0:00:00.046 6:00:33.077 5712 9 1728 Wait:UserReq 0:00:01.796 0:00:00.062 6:00:32.996 5496 9 1611 Wait:UserReq 0:00:01.531 0:00:00.046 6:00:32.981 3540 10 1847 Wait:UserReq 0:00:01.828 0:00:00.093 6:00:32.746 4644 9 1823 Wait:UserReq 0:00:01.843 0:00:00.015 6:00:32.738 6100 9 1643 Wait:UserReq 0:00:01.703 0:00:00.031 6:00:32.738 4564 9 1698 Wait:UserReq 0:00:02.187 0:00:00.046 6:00:32.735 3156 9 1727 Wait:UserReq 0:00:01.734 0:00:00.015 6:00:32.734 4464 9 1664 Wait:UserReq 0:00:01.703 0:00:00.046 6:00:32.732 3600 9 1730 Wait:UserReq 0:00:01.718 0:00:00.031 6:00:32.731 2000 9 1680 Wait:UserReq 0:00:01.468 0:00:00.015 6:00:32.723 5796 10 1436 Wait:UserReq 0:00:01.687 0:00:00.046 6:00:32.720 4932 9 1612 Wait:UserReq 0:00:01.718 0:00:00.046 6:00:32.720 1248 9 1886 Wait:UserReq 0:00:01.843 0:00:00.000 6:00:32.680 1076 9 1579 Wait:UserReq 0:00:01.656 0:00:00.062 6:00:32.674 4532 9 1594 Wait:UserReq 0:00:01.750 0:00:00.031 6:00:32.648 5084 9 1852 Wait:UserReq 0:00:02.156 0:00:00.015 6:00:32.644 2876 9 1690 Wait:UserReq 0:00:01.578 0:00:00.031 6:00:32.615 2188 9 1412 Wait:UserReq 0:00:01.890 0:00:00.031 6:00:32.612 5852 9 1578 Wait:UserReq 0:00:02.078 0:00:00.015 6:00:32.582 4944 9 1381 Wait:UserReq 0:00:01.750 0:00:00.031 6:00:32.488 2668 9 1508 Wait:UserReq 0:00:02.000 0:00:00.015 6:00:32.486 3860 9 1524 Wait:UserReq 0:00:01.546 0:00:00.046 6:00:32.484 3820 9 1829 Wait:UserReq 0:00:01.921 0:00:00.015 6:00:32.483 5668 9 1773 Wait:UserReq 0:00:01.890 0:00:00.031 6:00:32.481 1352 9 1950 Wait:UserReq 0:00:01.906 0:00:00.000 6:00:32.480 4112 9 1289 Wait:UserReq 0:00:01.843 0:00:00.046 6:00:32.397 4412 9 1407 Wait:UserReq 0:00:01.906 0:00:00.015 6:00:32.317 5696 9 1282 Wait:UserReq 0:00:01.828 0:00:00.078 6:00:31.234 5568 9 1564 Wait:UserReq 0:00:01.750 0:00:00.031 6:00:31.101 5596 9 1300 Wait:UserReq 0:00:01.312 0:00:00.031 5:57:28.019 348 9 804 Wait:UserReq 0:00:01.125 0:00:00.031 5:57:28.019 2252 9 1030 Wait:UserReq 0:00:01.062 0:00:00.031 5:57:27.998 1628 9 792 Wait:UserReq 0:00:01.421 0:00:00.000 5:57:27.997 2872 9 1148 Wait:UserReq 0:00:01.375 0:00:00.000 5:57:27.963 1040 9 1191 Wait:UserReq 0:00:01.453 0:00:00.046 5:57:27.962 5336 9 803 Wait:UserReq 0:00:01.265 0:00:00.015 5:57:27.952 1208 9 1087 Wait:UserReq 0:00:01.203 0:00:00.031 5:57:27.952 2204 9 1101 Wait:UserReq 0:00:01.109 0:00:00.031 5:57:27.850 6132 9 1043 Wait:UserReq 0:00:01.203 0:00:00.046 5:57:27.740 4436 9 892 Wait:UserReq 0:00:01.234 0:00:00.046 5:57:27.717 5536 9 833 Wait:UserReq 0:00:01.265 0:00:00.015 5:57:27.716 2232 9 958 Wait:UserReq 0:00:01.109 0:00:00.062 5:57:27.715 92 9 1028 Wait:UserReq 0:00:01.234 0:00:00.015 5:57:27.714 1292 9 1240 Wait:UserReq 0:00:01.171 0:00:00.015 5:57:27.691 5972 9 1402 Wait:UserReq 0:00:01.140 0:00:00.031 5:57:27.690 3844 9 1352 Wait:UserReq 0:00:01.234 0:00:00.078 5:57:27.682 4256 9 1018 Wait:UserReq 0:00:01.265 0:00:00.031 5:57:27.582 1012 9 986 Wait:UserReq 0:00:01.203 0:00:00.015 5:57:27.484 2540 9 1688 Wait:UserReq 0:00:01.375 0:00:00.046 5:57:27.483 2644 9 886 Wait:UserReq 0:00:00.875 0:00:00.062 5:57:27.475 920 9 963 Wait:UserReq 0:00:01.046 0:00:00.000 5:57:27.434 5564 9 1019 Wait:UserReq 0:00:01.203 0:00:00.031 5:57:27.379 5328 9 975 Wait:UserReq 0:00:01.296 0:00:00.031 5:57:27.372 5024 9 1054 Wait:UserReq 0:00:01.296 0:00:00.000 5:57:27.371 3288 9 1049 Wait:UserReq 0:00:01.203 0:00:00.062 5:57:27.350 5776 9 925 Wait:UserReq 0:00:01.281 0:00:00.031 5:57:27.346 788 9 658 Wait:UserReq 0:00:01.140 0:00:00.000 5:57:27.345 2600 9 1196 Wait:UserReq 0:00:00.921 0:00:00.031 5:57:27.299 3244 9 1512 Wait:UserReq 0:00:01.375 0:00:00.031 5:57:27.232 3160 9 714 Wait:UserReq 0:00:01.171 0:00:00.000 5:57:27.114 5764 10 1045 Wait:UserReq 0:00:01.140 0:00:00.031 5:57:27.107 5916 9 887 Wait:UserReq 0:00:01.062 0:00:00.031 5:57:27.099 4908 9 848 Wait:UserReq 0:00:00.937 0:00:00.031 5:57:27.098 2424 9 1589 Wait:UserReq 0:00:01.296 0:00:00.093 5:57:27.096 5744 9 1326 Wait:UserReq 0:00:01.343 0:00:00.046 5:57:27.073 5484 9 1011 Wait:UserReq 0:00:01.171 0:00:00.015 5:57:27.051 2508 9 862 Wait:UserReq 0:00:01.156 0:00:00.062 5:57:27.048 3372 9 889 Wait:UserReq 0:00:01.093 0:00:00.015 5:57:27.035 4608 9 662 Wait:UserReq 0:00:01.109 0:00:00.015 5:57:27.035 2004 9 432 Wait:UserReq 0:00:00.281 0:00:00.015 4:25:35.622 5816 9 306 Wait:UserReq 0:00:00.406 0:00:00.000 4:25:35.548 620 9 362 Wait:UserReq 0:00:00.359 0:00:00.000 4:25:35.501 6028 9 236 Wait:UserReq 0:00:00.468 0:00:00.000 4:25:35.415 3000 8 1 Wait:UserReq 0:00:00.000 0:00:00.000 1:00:43.815 3544 8 3 Wait:UserReq 0:00:00.000 0:00:00.000 1:00:43.815 3200 9 126 Wait:Queue 0:00:00.000 0:00:00.000 0:01:39.692 4632 8 4 Wait:Queue 0:00:00.000 0:00:00.000 0:01:39.692 304 8 6 Wait:UserReq 0:00:00.000 0:00:00.000 0:00:30.892 Name Pid VM WS Priv Priv Pk Faults NonP Page a2guard 4128 188088 7340 41912 51608 135607 46 304 Tid Pri Cswtch State User Time Kernel Time Elapsed Time 4132 12 362077 Wait:UserReq 0:00:00.718 0:00:00.906 6:58:55.557 4176 12 34603 Wait:UserReq 0:00:00.000 0:00:00.000 6:58:54.579 4180 2 243 Wait:UserReq 0:00:00.000 0:00:00.000 6:58:54.380 4196 10 5728 Wait:UserReq 0:00:00.140 0:00:00.328 6:58:54.286 32 8 2 Wait:Queue 0:00:00.000 0:00:00.000 0:00:44.533 3360 8 1 Wait:Queue 0:00:00.000 0:00:00.000 0:00:14.438 Name Pid VM WS Priv Priv Pk Faults NonP Page a2start 6072 213080 4564 58600 61880 456012 64 314 Tid Pri Cswtch State User Time Kernel Time Elapsed Time 6076 10 402826 Wait:UserReq 0:00:03.890 0:00:02.875 6:58:34.282 4264 10 26481 Wait:UserReq 0:00:00.015 0:00:00.015 6:58:33.048 4228 8 2 Wait:UserReq 0:00:00.000 0:00:00.000 6:58:33.032 4396 1 228 Wait:UserReq 0:00:00.000 0:00:00.015 6:58:33.032 5464 8 2064600 Wait:DelayExec 0:00:00.000 0:00:00.000 6:58:32.657 2284 10 241126 Wait:DelayExec 0:00:00.000 0:00:00.015 6:52:44.222 4940 8 1 Wait:Queue 0:00:00.000 0:00:00.000 0:00:14.500 212 8 1 Wait:Queue 0:00:00.000 0:00:00.000 0:00:14.500 C:\> The machine was last booted around 7 hours ago, which would (I suppose) correlate with the near-7 hour elpased time value on some detail lines.
  16. > Why not just check the timestamps on the files? Because they don't tell me that an update process /started/. > Also, as I mentioned before, the time and update starts and ends does get logged. If it includes the time that the process ends, that log record must be written at the end of the update. In my example of three days with no updates occurring, there were no log records. It is impossible to tell whether umpteen update attempts started and got nowhere. It's also (according to you) not possible that a manual update would work (which it did) when automatic updates are stalled. So there's a big mystery about why the expected hourly updates did not happen.
  17. > I'm not really sure we're getting anywhere. The issue happened, then was resolved, and hasn't > happened again. I agree we're not getting anywhere. But I don't agree that the issue was resolved. We have no idea why /automatic/ updates failed to happen for three days, then a manual update worked. > As for debug logs, these are not a design defect. ... They're fine so far as they go, but the chicken-and-egg problem of needing logging on to find out if there's a problem, but not having logs on until after you've seen a problem has no solution if you're not willing to find a way around it. I still think that there's doubt over whether your scheduler always starts update attempts when it is meant to. If you won't add a log record to say so, another option would be to create a empty file in: %TEMP% with a name like: EIS update started at yyyymmdd hhmmss.log and delete it again when an update process runs to completion. I'm not suggesting it should go in a2temp, because /if/ a user should end up with lots of those flag files, they would be much less likely to find them if they were in \a2temp. Whenever anyone complains about an updating problem you could ask if any such files exist.
  18. Arthur, see PM for a full set of debug logs for 24th-29th, and a summary of climbing memory use over that period.
  19. > Getting a hold of an old build isn't difficult, however keeping it is. The updater will automatically > download and install the latest version unless you disable updates. And that would also prevent signature updates? I wouldn't want to do that for very long.
  20. > If you could start an update while a previous update appeared to be frozen/stalled, then > the previous update wasn't actually stalled and it may have just been a UI glitch. A three-day failure to update its signatures, AND no decent alert to the user saying that there was a problem is FAR MORE than a 'UI glitch'. It's a serious fault. I note that in another thread someone else recently complained that the tiny systray shield's colour-change is just not adequate, especially for older eyes on high-res screens - as a way of notifying the user of a serious issue. [http://support.emsisoft.com/topic/20090-eam-shows-no-protection/] > It would also double the number of rows in the update log table of the SQLite database, which > would cut the number of updates that get logged in half. This is the sort of thing that we > generally keep in debug logs rather than in regular logs. ... which would be fine if anyone ever had debug logging on when this occurs. Debug logs are no good for things that users can't reproduce. You must know that. > [killing stalled updates] That wouldn't solve the problem, and the user would be in the same > bad situation. No updates, and no clue why. Not correct. I see you snipped my suggestion that when such a 'kill' is done, it would be logged. So while, yes, it wouldn't fix the problem - but then no-one seems to understand how to fix the problem - it would not the leave the user without any clue. There would be a log entry saying that the stalled update had been detected. At least we'd then all know that these presumed stalled updates were really happening. > Debug logs are the way that developers find out where a problem in the software is. Without them, > they have no way to know why something isn't working as expected. They can't just go through > millions of lines of code and hope they stumble upon the part of the code that is causing the > problem, and just so happen to notice an issue with that code that they overlooked when they > wrote it/updated it. The only time bugs get fixed without debug logs is when our QA team can > reproduce the issue in their own testing. Then you have a fundamental design problem, don't you? Debug logs are not "the way", they're just one way of finding out why things don't work. There needs to be a middle ground, where when users never have debug logging on when a problem occurs, developers have to find another way to collect basic info - maybe not enough to pin down exactly why something is going wrong, but enough to /prove/ that it is. I lead a programming team before illness forced me to stop work. We occasionally had this sort of problem, and fixed it with a basic trace that ran all the time in whichever specific part of our product until the reported problem happened again. We were lucky (compared with you) that our customers were on a corporate network and so we were able to have our product send those small log files to us automatically and we received and filtered them automatically until one showed what we needed to know. Obviously you can't, in these days of angst about apps that 'phone home', have EIS send logs to you without the customers knowing, but it should be possible to create (if you like) an extra log that records some small details about the start and stop of the update processes. If you're so concerned about its impact on the SQLite databases put it somewhere else. It has to be active all the time so that it's active when people hit the problem. But for goodness sake, do something about this problem. > Obviously, if our management thinks that adding some of your suggestions is a good idea, then > they will have our developers work on it. Do your management know about any of my suggestions?
  21. > We already have error handling ... Adding more folders just adds complexity ... Hmmm. Even YOU agreed in your 20160318 1128 post that this area needs more work. Do the developers agree that the present situation is not good enough?
  22. If there's a way to, and if it would help your developers, I'd be willing to install an older build to see if the problem goes away.
  23. Periodically in the last couple of weeks, I've cross-checked Process Hacker's figures with that of Task Manager (in W8.1), and here, they've always agreed with each other. It's interesting that Yilee sees the problem on W7 Ultimate (on a desktop?) and on a laptop (precise OS unstated above, maybe W7?), and I on W8.1, both of us with 64 bit systems. Also, my machine has "activate memory usage optimization" turned on, and has done ever since I installed EIS on 28th Feb 2016 (I looked back to my install notes where I'd noted the settings I chose to start with). So if that setting is relevant, it was harmless until the reported start of this problem. I did a full shutdown & reboot again over the weekend, but this time turned debug logging on just before I shut the system. Possibly later today, depending on how high the memory use has climbed to (it's doing it steadily but I've not been awake so much in the last few days), I'll shutdown & reboot and then make the debug logs for the whole time: boot through to shutdown available to you.
  24. OK, just summarising where I think this discussion has got to. I think I'm waiting for the developers to answer two questions you've passed to them, namely: a) (as described in your post, which I see datestamped as 20160318 1128): - developer comments on using separate folders for each set of update files acquired to reduce chance that a problem with the current single specific 'a2temp' folder, maybe from a previously stalled update might somehow interfere with a newer update attempt b) (as described in your post, which I see datestamped as 20160421 0555): - developer comments on why cancel didn't work
  25. OK... your first & second answers make it clear that you think there was a stalled update preventing any other automatic updates from starting. But you then say that a manual (check for) updates would be impossible - it would just show the current one's progress. But right at the start of this discussion I told you that I triggered a manual update, which worked immediately. To me, that suggests that there wasn't a stalled update, but instead a scheduling problem. This is why I keep suggesting that a log entry saying that a scheduled update is about to start, would be a good thing. If stalled updates really do block other attempted updates from starting maybe your suite needs deliberately to look for update processes that started - say - more than 3 hours ago, and kill them. And, if it did do that, LOG that it found such a problem and tried to fix it. Unless the developers start trying to find where the problems lie, I don't think this will ever get fixed. I've been an EMSI customer for quite a while, and I've read loads of threads which boil down to updates not happening when people expected them to. Constantly being told that 'debug logs' are needed to solve the problem just isn't good enough. We all know that nearly no-one has debug logs active when problems occur. I'm tryin to suggest things that might help pin down where the problems are.