JeremyNicoll

Member
  • Content Count

    1818
  • Joined

  • Last visited

  • Days Won

    28

Posts posted by JeremyNicoll


  1. If a new install fixes the problem, surely someone should be curious about why?    The updated product is meant to be the same

    as a fresh install.   If it's not, surely someone at Emsi should be curious about what is wrong with the install.   So, if you'll tell me 

    which bits of the registry, any files outwith   C:\Program Files\Emsisoft Internet Security   and anything else that I should backup

    first, and then copy again after such an install, so that you guys can look at these things to see what has been changed, I suppose

    I could try it.

     

    I do understand the point that was made earlier, that any trusted application could have altered registry keys etc that might matter.

    But I don't understand why, if that's the case, "self-protection" doesn't prevent that from happening.  

     

    I have another product whose author was driven mad by (naive) users constantly complaining that a component had unregistered

    itself.  Although he knows that the problem was users running registry cleaners and deleting eveything the cleaner suggested, and

    explained this to such users, that did not stop the support requests.  Eventually he changed the product so that, in essence, it

    reinstalls the licence registry keys every time it starts.

     

    It seems to me that your product could, immediately after an install, store encrypted copies of critical registry data (if indeed this is

    the problem) and - if not replace them, if the same entries are no longer present later on - at least log/alert saying that required

    registry entries have been damaged.    


  2. I haven't, because I don't see why the product installed and working fine, then updated automatically, should need it.

    (And actually, I wasn't asked to do a reinstall.)

     

    If a file was obviously corrupt or missing, fair enough...    If the developers think the code could have become corrupted

    somehow, I'd rather someone made some effort to find out what is wrong, before a reinstall overwrites/resets anything.

    Else, how will they ever find out how to stop such changes from breaking an install?


  3. > No, I was simply explaining how memory usage can increase during certain activities  ...
    > Private Bytes, in my own testing, usually hover somewhere in between 500MB and 600MB

    It's perfectly clear that not everyone has this problem.  Seeing over & over again that
    your system doesn't have it, isn't helping finding out why my system does.


    With regard to my discovery of the "WKMT" literal only in your fw... drivers, last night,
    then I only searched the *.sys files in C:\Windows (and its subdirectories), and in
    C:\Program Files\Emsisoft Internet Security\      but since then I've run a search across
    all *.sys files on the disk... and still the only files containing that literal are the
    Emsi ones.
            


  4. I've made some progress.

    A long way further up this thread (eg post eight) I described how I was seeing very high use of the
    non-paged pool of virtual memory.  This is kernel virtual memory which is always swapped-in, so
    is in essence permanently allocated REAL memory.

    I found a series of articles explaining ways of diagnosing memory leaks that allocate and then never
    free such memory, starting here:

    https://blogs.msdn.microsoft.com/ntdebugging/2012/07/31/troubleshooting-pool-leaks-part-1-perfmon/

    In particular the second article:
    https://blogs.msdn.microsoft.com/ntdebugging/2012/08/30/troubleshooting-pool-leaks-part-2-poolmon/

    describes use of a tool named 'poolmon' which MS currently ship with their WDK (Driver Kit) as a
    tool for people developing drivers. In essence, when drivers request this sort of memory, they are
    meant to do so with a 4-byte 'tag' that's unique to that driver developer, and perhaps even to a
    driver or even a particular part of the logic in one driver.  The poolmon tool lets you see the
    kernel memory allocation in both the paged and non-paged pools, by tag.

    I installed the WDK and ran poolmon, with an option that sorts its display by the number of bytes
    of memory allocated under each tag.  As the screenshot shows, a bit more than 5 GB of REAL MEMORY
    has been allocated to requests made under tag "WKMT".

    This literal does not exist in any *.sys file inside C:\Windows  and its subdirectories.

    It DOES exist in these four files:

      C:\Program Files\Emsisoft Internet Security\fwwfp32.sys
      C:\Program Files\Emsisoft Internet Security\fwwfp732.sys
      C:\Program Files\Emsisoft Internet Security\fwwfp64.sys
      C:\Program Files\Emsisoft Internet Security\fwwfp764.sys

    This looks to me as if your drivers are causing this problem.

     

    20160416 2150 08 (Poolmon screenshot on 20160518 0138).bmp


  5. Are you seriously suggesting that having "Activate memory usage optimisation" selected would cause Private Bytes (PH) or 'commit size'

    to increase from around 500 MB to (now) 1944 MB? 

     

    Your own blog: http://blog.emsisoft.com/2016/04/13/why-antivirus-uses-so-much-ram-and-why-that-is-actually-a-good-thing/   says that the whole

    signatures db is around 200 MB.  It'd need to be "moved back into RAM" seven times in its entirety to account for an extra 1400 or so MB.  

     

    How big is the host rules part of the db?

     

    Seeing as I /did/ provide debug logs, is anyone actually going to look at them?


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


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


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


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


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


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


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


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


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


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


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


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


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


  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.