Author Topic: Developers, please explain what this log entry means  (Read 1129 times)

0 Members and 1 Guest are viewing this topic.

Offline InvisibleMan

  • Full Member
  • ***
  • Posts: 133
Developers, please explain what this log entry means
« on: September 07, 2022, 04:30:43 AM »
Hello!

It's really been frustrating for the past year, and no developer (who even tried) was willing to tell me what's causing this issue!

Windows 7 SP1
Avast Free 22.8.6030

This file:
Code: [Select]
C:\ProgramData\Avast Software\Avast\log\AvastUI.log
This repeating entry (every three seconds, ALWAYS)!
Quote
[2022-09-07 02:22:04.206] [info   ] [swhealth_ui] [ 6268: 4184] [3E6B5C: 149] Connecting service controller
[2022-09-07 02:22:04.206] [warning] [swhealth_ui] [ 6268: 4184] [3E6B5C: 183] Failed to initialize:   Rpc call failed
                                                                                 SoftHealth_State failed (1753)

It reduces the life time of my HDD! And there's no proper way to turn this log off!

(Not to mention, that along with it, the memory consumed by AvastUI.exe (one of the four processes) keeps climbing into infinity, about 50 MB per day, unless I open and close the Avast UI window, which resets it.)

I tried everything already. Avast isn't blocked anywhere in Firewall, but still it does the same thing.
I even tried disabling Firewall completley on my PC for a minute. It didn't change a thing!

Please, can any developer finially tell me what is CAUSING it, so I can at least solve this myself?

Is it something Windows 7 only related?

Could it be because I have remote control disabled in Window's settings, but Avast tries to gain some remote control of my computer?

I don't know what to think anymore.

You developed this program, so I you surely know what that log entry means. And all I wish is to know what reasons can be causing it.

I already tried solving it twice with other developers via bug report, and there was no reasult.
So, bug reporting this issue is a waste of time.

I'm prepared to deal with the issue myself, if you could just point me out in the right direction.
« Last Edit: September 07, 2022, 05:08:51 AM by InvisibleMan »

Offline InvisibleMan

  • Full Member
  • ***
  • Posts: 133
Re: Developers, please explain what this log entry means
« Reply #1 on: September 07, 2022, 04:53:06 AM »
All I could find online myself about this error in general (nothing helpful related to avast specifically) is on the following page:
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/replication-error-1753-there-are-no-more-endpoints-available-from-the-endpoint-mapper

Quote
Failure 1753 is generated by a failure between steps #3 and #4. Specifically, error 1753 means that the RPC client (destination DC) was able to contact the RPC Server (source DC) over port 135 but the EPM on the RPC Server (source DC) was unable to locate the RPC application of interest and returned server side error 1753. The presence of the 1753 error indicates that the RPC client (destination DC) received the server side error response from the RPC Server (AD replication source DC) over the network.

Specific root causes for the 1753 error include:

    The server app never started (i.e. Step #1 in the "more information" diagram located above was never attempted).
    The server app started but there was some failure during initialization that prevented it from registering with the RPC Endpoint Mapper (i.e. Step #1 in the "more information" diagram above was attempted but failed).
    The server app started but subsequently died. (i.e. Step #1 in the "more information" diagram above was completed successfully, but was undone later because the server died).
    The server app manually unregistered its endpoints (similar to 3 but intentional. Not likely but included for completeness.)
    The RPC client (destination DC) contacted a different RPC server than the intended one due to a Name to IP mapping error in DNS, WINS or host/Lmhosts file.

Whatever the reason is, why does Avast have to write down this error into the log ALL the time, every three seconds?

Could it instead write this error down once a minute if it happens anyway or something like that?

Offline r@vast

  • Avast team
  • Massive Poster
  • *
  • Posts: 2761
Re: Developers, please explain what this log entry means
« Reply #2 on: September 09, 2022, 11:03:54 AM »
Hi,

The log entries relate to Patch Management. It often happens if UI starts before Avast Service is fully initialized, for instance, just after installation or update.
Our developers are looking into improving the GUI logging.

Offline InvisibleMan

  • Full Member
  • ***
  • Posts: 133
Re: Developers, please explain what this log entry means
« Reply #3 on: September 09, 2022, 07:38:06 PM »
Hi,

The log entries relate to Patch Management. It often happens if UI starts before Avast Service is fully initialized, for instance, just after installation or update.
Our developers are looking into improving the GUI logging.
Hello!

Thank you for replying!

Talking of GUI, in case it might be helpful to identify this issue even better:

I tried (for several times) to disable the Avast self-defense temporarily and completely kill ALL the AvastUI.exe processes in the Task Manager, then run the AvastUI.exe (by the default Avast's shortcut), and re-enable self-defense.

The result: the issue of that error being logged every 3 seconds remained. Though a couple of times it seemed for a minute or so, that it stopped, but soon the problem was back.
If it was only because of the UI starting before the Service was fully initialized, wouldn't such UI restart actions fix it?

Also, I don't know if this error is the reason, but on the recent version of Avast Free (and on the older ones for months) there is a memory leak in one of the four AvastUI.exe that are always present by default in the Task Manager. It eats up about 30 - 50 MB per day, and never stops, unless I open the Avast GUI window and close it, which does free the memory (though it doesn't reduce the amount of the "Committed memory" for the process).

(For now I've been trying to fight this issue via setting that log file as "Read Only", but that's not a good solution).