JeremyNicoll

Member
  • Content Count

    1760
  • Joined

  • Last visited

  • Days Won

    26

Posts posted by JeremyNicoll


  1. 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?


  2. > 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.


  3. > 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?


  4. > 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?


  5. > 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?  


  6. > 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.  


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


  8. 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.


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


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


  11. > 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.


  12. > 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.


  13. > 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.
                                                                                             


  14. > 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?


  15. 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.


  16. 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


  17. 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.