Author Topic: Ashavast.exe - stalls as local user, causes multiple processes, runs CPU to 100%  (Read 36646 times)

0 Members and 1 Guest are viewing this topic.

Online DavidR

  • Avast Überevangelist
  • Certainly Bot
  • *****
  • Posts: 88895
  • No support PMs thanks
Surely you would have the same problem editing registry entries as a limited user and that isn't an avast issue but a windows restriction.

I can't recall if you can even edit user keys in a limited user account ???

So you may have to do those edits from an account with admin privileges.
Windows 10 Home 64bit/ Acer Aspire F15/ Intel Core i5 7200U 2.5GHz, 8GB DDR4 memory, 256GB SSD, 1TB HDD/ avast! free 24.2.6105 (build 24.2.8918.824) UI 1.0.799/ Firefox, uBlock Origin, uMatrix/ MailWasher Pro/ Avast! Mobile Security

Offline igor

  • Avast team
  • Serious Graphoman
  • *
  • Posts: 11849
    • AVAST Software
If you check the permissions to this key in regedit - what does it show?

blue2

  • Guest
That is EXACTLY, step by step, the procedure I followed the last time. See my reply #28 of two weeks ago.

I assume I should disable self-defense before attempting to uninstall.

I will try this one more time with the new build, if this is what Vik suggests is the best approach. I've followed everyone's suggestions over the past two weeks, but what takes a few minutes to suggest, sometimes takes hours of work to implement, on a machine that I don't have constant access to.

I'm not as well versed as you all in this program, but I've solved a pretty good number of computer problems by starting from the most logical culprits, instead of just blindly installing new builds. I said at the very beginning that I had the distinct impression this was some kind of privilege issue. I could set the privileges of the program to all users but that seemed to me to be compromising the security of the program.

I installed this as a favor for a friend, and did not expect to have the installation of Avast take more time than it would take to clean up an infected system.

Igor, I will check the permissions on this key now.

blue2

  • Guest
DavidR, I didn't even get to edit this key. I merely tried to view the key for the current user and could not. I think that is rather odd.

I'm no registry expert, but how could one possibly edit the key of the current user while under the Administrator account, which is not the current (limited) user?

Igor, when I check the permissions of the 4.0 branch, it states "You do not have permission to view the current permission settings for 4.0, but you can make permission changes." when I then click "Ok", it shows nothing, no users, no permission settings. When I move up the branch to Avast or ALWIL software, it clearly shows the permissions of the local user as well as the system and administrator.

Now what could possibly have caused this issue?

Offline Vlk

  • Avast CEO
  • Serious Graphoman
  • *
  • Posts: 11658
  • Please don't send me IM's. Email only. Thx.
    • ALWIL Software
Can you please try to access the key from Windows Safe Mode?
No part of avast is running in Safe Mode so we can easily conclude if the key is made inaccessible by avast itself or something else.

Thanks
Vlk
If at first you don't succeed, then skydiving's not for you.

blue2

  • Guest
Vik, if I boot into Safe Mode, I can of course only log in as Admin not as a local user. In safe mode, in the Admin account, I can navigate to the HKCU key without problem, and see the three sub-branches (ahsLogV, ashSimp2 and ashUInt, just as I normally see for this key as the Admin. But it does not show me the permissions for the limited user account since the current user is then the Admin.

Did I not understand something?

Offline Vlk

  • Avast CEO
  • Serious Graphoman
  • *
  • Posts: 11658
  • Please don't send me IM's. Email only. Thx.
    • ALWIL Software
Oops, sorry, forgot we're talking about HKCU, not HKLM.

What you could try to do is mount the HKCU hive of the non-admin while logged on as an admin (either from the Safe Mode, or from a regular Windows mode).

To do this, navigate e.g. to HKEY_USERS, go to menu File ->Load Hive, and navigate to C:\Documents And Settings\<name-of-the-non-admin-account>. Then select the file ntuser.dat. This should make regedit load the HKCU hive of that user to a new key inside HKU.

Having done that, please try to navigate to the Software\ALWIL Software\Avast\4.0 branch. Is that possible?

Thanks
Vlk
If at first you don't succeed, then skydiving's not for you.

blue2

  • Guest
Just to confirm, am I only mounting the local user hive while the Admin, just to see if I can navigate to that 4.0 key and see what it's permissions are? Or am I attempting to add the previously suggested additional value to the 4.0 key in the local user hive of the registry?

You can understand my hesitation. A registry error like before (to add the value to create the dump file), created a good half a day of work when the system wouldn't load. In which case, it'd be easier to try the latest build. But if there is some kind of privilege issue, and the two previous builds had this issue, it's likely that whatever caused it, will cause it again in the latest build.

Since this thread has become quite long, let me just reiterate the two symptoms I thought significant:

1. I can't get the Ashavast.exe process to run as limited user, but can as admin or using "run as" as limited user. Other functions (quick scan, udpate, etc.) work fine as local user. As local user, Ashavast.exe stalls, does not open, and the process runs CPU at 100%. If I click it again, it opens a second Ashavast.exe process, both stalled.

2. If I then try to terminate the process in task manager, I get an "Unable to Terminate Process. Access is Denied" message. The only way to terminate is to reboot. And that displays an "Active Skin Helper can't shut down" message and I need to kill Active Skin Helper to force the reboot.

This is what led me to question whether this is a permission issue and if the way that Active Skin Helper is being called by Avast is somehow invoking something else (a dll perhaps) that requires elevated privileges to run, thereby hanging the process. I tried installing without skins and using only the simple user interface, but it made no difference.

Did the full memory dump indicate anything more specific? Did it indicate what was hung, e.g. dependent dlls?
« Last Edit: May 30, 2008, 11:30:28 AM by blue2 »

Offline Vlk

  • Avast CEO
  • Serious Graphoman
  • *
  • Posts: 11658
  • Please don't send me IM's. Email only. Thx.
    • ALWIL Software
Primarily, the point is to find out if the hive isn't corrupted.
Secondly, it would be interesting to find out what its access permissions are.

Thanks
Vlk
If at first you don't succeed, then skydiving's not for you.

blue2

  • Guest
I'm sorry, but I don't understand what you’re asking. It's going to require a little more guidance, since an oversight results in hours of needless work.

Just in case, I’ve tried the latest Avast build. As suspected, it was not a "magic" solution.  The process was: uninstalled the present build, rebooted, used the clear utility, rebooted, then swept the registry for ALWIL/Avast.  I still saw a limited user key HKEY_CURRENT_USER\Software\ALWIL Software\Avast\4.0, but could NOT get to the 4.0 level nor could I delete the key. Then I rebooted, installed the latest build (without any skins, simple user interface), rebooted. No problem as admin but the program still hangs as local user.

-- Now how could an Avast key be created that can't be removed? It’s unlikely to have been "corrupted" by anything since Avast was the last thing installed. I even held off installing XP SP3 for that reason. If something could corrupt it without trying, that makes me wonder what malware could do!

I've used the Hang Rep utility and FTP’d a full 650mb memory dump.

-- No one ever answered my question of whether that showed anything?

You suggestion: “mount the HKCU hive of the non-admin while logged on as an admin (either from the Safe Mode, or from a regular Windows mode).

To do this, navigate e.g. to HKEY_USERS, go to menu File ->Load Hive, and navigate to C:\Documents And Settings\<name-of-the-non-admin-account>. Then select the file ntuser.dat. This should make regedit load the HKCU hive of that user to a new key inside HKU.

Having done that, please try to navigate to the Software\ALWIL Software\Avast\4.0 branch”

-- What exactly does that mean? Is that simply “reading” the local hive while running as administrator in safe mode, or is that “writing” changes” to the registry, that might have undesirable consequences?

-- Again, am I only mounting the local user hive while the Admin, just to see if I can navigate to that 4.0 key and see what it's permissions are? Or am I attempting to add your previously suggested additional value to the 4.0 key in the local user hive of the registry?

I don't fiddle around in the registry UNLESS there is a specific key to modify. Once you start talking about hives, it is not clear to me if this is reversable or not. The last suggested registry modification I followed forced me to reinstall, so I'd like to be sure we understand each other.

And nothing that has been suggested thus far indicates to me that my suspicion that this is a permission-related issue is incorrect. If so, your programming team must surely know what the underlying program privileges are to see what could be screwed up and to explain how?

Thanks.

Offline igor

  • Avast team
  • Serious Graphoman
  • *
  • Posts: 11849
    • AVAST Software
-- Now how could an Avast key be created that can't be removed? It’s unlikely to have been "corrupted" by anything since Avast was the last thing installed. I even held off installing XP SP3 for that reason. If something could corrupt it without trying, that makes me wonder what malware could do!

The registry hive itself may be corrupted (might have been corrupted before avast! was installed, who knows) - in that case, all kinds of strange things might happen.

I've used the Hang Rep utility and FTP’d a full 650mb memory dump.
-- No one ever answered my question of whether that showed anything?

The dump revealed a strange piece of code (I guess it can be called a bug) that causes the reported 100% CPU usage. However, this bug manifests only if a specific registry value cannot be read from avast! key.
Now, this may happen if somebody deleted the key/value manually - but that's not the case here. So, the primary cause here must be something else.

You suggestion: “mount the HKCU hive of the non-admin while logged on as an admin (either from the Safe Mode, or from a regular Windows mode).

To do this, navigate e.g. to HKEY_USERS, go to menu File ->Load Hive, and navigate to C:\Documents And Settings\<name-of-the-non-admin-account>. Then select the file ntuser.dat. This should make regedit load the HKCU hive of that user to a new key inside HKU.

Having done that, please try to navigate to the Software\ALWIL Software\Avast\4.0 branch”

-- What exactly does that mean? Is that simply “reading” the local hive while running as administrator in safe mode, or is that “writing” changes” to the registry, that might have undesirable consequences?

If you just navigate to the key (or display its permissions), no writing operation will occur.

-- Again, am I only mounting the local user hive while the Admin, just to see if I can navigate to that 4.0 key and see what it's permissions are? Or am I attempting to add your previously suggested additional value to the 4.0 key in the local user hive of the registry?

Well, if the permission shows something strange (but again - who would set the special permission there? It's HKEY_CURRENT_USER, i.e. the restricuted user should have full access rights there), there's no need to create anything. If the permissions seem OK, it would be interesting to try to create the key (as Admin). If this fails, I'd say it's a sign that the registry hive is corrupted.

I don't fiddle around in the registry UNLESS there is a specific key to modify. Once you start talking about hives, it is not clear to me if this is reversable or not. The last suggested registry modification I followed forced me to reinstall, so I'd like to be sure we understand each other.

Of course, you can back up the Ntuser.dat file before loading the hive into regedit.
Honestly, I don't see any way how changes (even corruption) of a limited user account registry hive could cause the system to fail to boot - this hive is not touched/loaded if you log on as a different user.

And nothing that has been suggested thus far indicates to me that my suspicion that this is a permission-related issue is incorrect. If so, your programming team must surely know what the underlying program privileges are to see what could be screwed up and to explain how?

As I wrote above - any user normally has all rights for "his" HKEY_CURRENT_USER hive. In your case, it seems that the user isn't able even to read/browse this key - it's very strange. avast! doesn't set any restriction on its keys... so unless somebody (user, or some other software) changed the permissions itself, there shouldn't be any problem here.

blue2

  • Guest
As administrator I've loaded the limited user hive in HKEY_USERS. (The hive IS written and remains unless one knows to go back to the menu under HKEY_USERS and selects "unload hive". I didn't know but figured it out. But that's what I meant before about unforseen consequences if procedures are not spelled out PRECISELY.)

When the limited user hive is loaded, the permissions are only Admin, Restricted, System and S-1-5-21...., so that's why it can't be changed as a local user.
--> So is there a way to load this hive as admin, make the necessary changes, and then replace the actual limited user hive with this modified temporary hive? Or is there some other suggested procedure to follow?

When I look at this limited user hive, the branch goes Software\ALWIL Sofware\Avast\4.0\ and then there are sub-branches for ashSimp and ashUint. However, when I look at the adminstrator branch, the branch ends at 4.0 without these two sub-branches.
-->Is that the way it is supposed to be?

On the administrator hive, in Software I see Symantec\ with branches to Common and Systemworks, and also Software\Symantec\Norton Utilities. Both of these branches have permissions to all users, but both will not let me delete them. To get rid of Norton I had used both Add\Remove, the Norton Removal Tool and also swept the registry for Norton\Symantec\NAV.
-- >Is there a procedure to delete keys that won't permit deletion?

Now there is only one additional thought that occured to me. I had changed the SID on the machine using NewSID (which then changes the SID ids for each user). Is it possible that when the SID id for the limited user account changed, it somehow caused an issue, but only with security apps? Are they "tied" to SIDs somehow? Other than this, I see no evidence of hive "corruption" in event viewer.

P.S. By the way, the machine was previously prevented from rebooting not because I was asked to read something in the local hive, but rather asked to add a registry value to create a full dump and then intentionally blue screen the machine and reboot. That did not work as intended...

blue2

  • Guest
Well, some progress.

I've gotten Avast to work as a limited user simply by loading the local hive as admin, navigating to the Avast\4.0 key and changing the limited user account permission to FULL CONTROL. Then when I logged on as the limited user, the changes took effect and Avast worked.
-->Is that correct as I don't want to make an error and compromise the machine's security? Meaning, on the HKCU hive while a limited user, should that user have full control over those Avast keys? Is there some further testing that should be done to be sure that it is working correctly?

On this limited user hive, the branch goes Software\ALWIL Sofware\Avast\4.0\ and then there are sub-branches for ashSimp and ashUint. However, on the adminstrator hive, the branch ends at 4.0 WITHOUT these two sub-branches.
-->Is that correct?

On the administrator hive, in Software I see Symantec\ with branches to Common and Systemworks, and also Software\Symantec\Norton Utilities. Both of these branches have permissions to all users, but will not let me delete them. I don't think these had any effect on the issue, and it's odd that they are still there since I had used Add\Remove, the Norton Removal Tool and swept the registry for Norton\Symantec\NAV.
-- >Is there some other procedure to delete these keys that won't permit deletion?

Thanks.