Avast WEBforum
Business Products => Avast Business => Cloud Management Console & Clients => Topic started by: kevrianate on October 29, 2015, 04:15:03 PM
-
After spending an hour trying to figure out how to get access to c:\windows\temp I found another thread in the avast free forum saying that it is Avast's self defense mode causing this. I disabled self defense and can now access c:\windows\temp. Is there any reason why self defense is completely locking that directory? I cant even change permissions when its active.
-
Interesting coincidence, last week we needed to clean the Temp folder on a computer and noticed the same situation you are describing. The folder was inaccessible even after checking security permissions and ownership. It seems that Avast keeps a lock on just one sub-folder (based on messages during ownership change) but the rest of the folder also appears locked for normal access.
Will subscribe to this topic for notifications in case we get a word from Avast.
-
The temporary "fix" is to disable Avast's self protection, that frees the lock up so you can clean the directory up.
-
What OS/SP ?
What exact version of avast ?
I can access the temp folder (and move/delete files) without a problem with the self defense mode enabled.
Windows XP - SP3
avast version 2015.10.2.2505
-
Windows 10 Professional x64
Avast Business Security 1015.10.2.2505
From what I have been able to find this doesnt happen to a lot of people but it does happen. I found another older thread for another avast product that caused this issue.
-
It would not surprise me if the combination of avast (business product) + windows 10 is the culprit.
The endpoint suite also has problems with Windows 10
-
The version I am using is compatible with Windows 10.
-
Wanted to add that Windows 7 Pro x64 is exhibiting the same behavior as described by kevrianate on his/her Windows 10 installation.
-
I'm curious to know why people would want to fiddle in this directory?
Your user TEMP environment variable should be set to %USERPROFILE%\AppData\Local\Temp (see http://environmentvariables.org/Temp (http://environmentvariables.org/Temp)), and %SystemRoot%\Temp is a haven for malware so locking it from the user seems sensible-ish.
If you're trying to clean it up, does Desk Cleanup tool still work?
-
I'm curious to know why people would want to fiddle in this directory?
Your user TEMP environment variable should be set to %USERPROFILE%\AppData\Local\Temp (see http://environmentvariables.org/Temp (http://environmentvariables.org/Temp)), and %SystemRoot%\Temp is a haven for malware so locking it from the user seems sensible-ish.
If you're trying to clean it up, does Desk Cleanup tool still work?
I am working on an application that uses %systemroot%\temp for temporary storage while transferring files and found that I started receiving an error while doing this which I tracked down to Avast. When self protectoin is active I cant do ANYTHING with that directory, even enter it as an administrator.
-
I am working on an application that uses %systemroot%\temp for temporary storage while transferring files and found that I started receiving an error while doing this which I tracked down to Avast. When self protectoin is active I cant do ANYTHING with that directory, even enter it as an administrator.
Interesting! Is this an application you are developing or a 3rd party app that isn't working properly? I assume the former.
I have tested a Windows 7 (x86) and Server 2012 R2 (x64) and it works fine for me with 2015.10.2.2505 as an Administrator. From the sounds of it, it is something specific to your (and some other people's) environment. Might be worth logging a support ticket with Avast.
Do you have the same troubles with %USERPROFILE%\AppData\Local\Temp ?
I don't really have any answers, but I'd suggest if running under Administrator context it's probably using the system env variable, whereas if running as a standard user it should be using the user env variable and not using %systemroot%\temp (unless the user variable is missing or changed). %systemroot%\temp must still be usable somehow even with Avast self-defense on, or Windows would simply come grinding to a halt :) Try running under a different user context (ie not administrator if you can), it might help to show something.
-
I would use a temp folder under the application folder.
-
Do you have the same troubles with %USERPROFILE%\AppData\Local\Temp ?
No, I can access that folder without any problems. I dont have any control over where the app stores its data and the target machine doesnt use avast so it wouldnt have this issue.
-
You are working on a application and you don't have control where it stores temp data?
That doesn't make sense to me.
-
Do you have the same troubles with %USERPROFILE%\AppData\Local\Temp ?
No, I can access that folder without any problems. I dont have any control over where the app stores its data and the target machine doesnt use avast so it wouldnt have this issue.
I logged into my test machine as a non-administrative user and had this problem. Even after entering correct admin credentials at the prompts I got the access denied message. But after I disabled the self-defense and tried to view the c:\windows\temp (after jumping through security hurdles again), my user account was added by Windows to the folder's security with full control and was able to access the folder even when self-defense was enabled again.
I don't know a lot about this mechanism. It appears Avast is not letting Windows apply the security once automatically. Could be a bug, or by design. In either case, I'd suggest logging a support ticket with Avast if your user account is not applying by itself.
So this could explain why some people have problems and some don't. It could be some users have accessed c:\windows\temp before Avast was ever installed and the security was set correctly.
@kevrianate, are you the application developer or not? Why can't you change the location? In general you should not be hard-coding %systemroot%\temp as you might fix the security for one non-administrative user, but not all, and your permissions will be lost if you reinstall Windows etc. This location is a throwback to the Win95 days and is mostly just for Windows internal system use which is why it is now much more secure than in the past.
If you must use %systemroot%\temp, try running the app using Program Compatibility Troubleshooter, or apply appropriate security to the folder yourself (but I disapprove of this!).
-
You are working on a application and you don't have control where it stores temp data?
That doesn't make sense to me.
Im not working on that part of the application plus this only occurs on my development box and the app is used under windows xp which defaults to c:\windows\temp for the temp directory.
-
Im not working on that part of the application plus this only occurs on my development box and the app is used under windows xp which defaults to c:\windows\temp for the temp directory.
No, XP's user default is NOT c:\windows\temp. TEMP and TMP for a user are set to %SystemDrive%\Documents and Settings\{username}\Local Settings\Temp by default. If this is not the case, it has been changed, and it should NOT be changed to be the same as the system variable which IS %systemroot%\temp. User and System variables are two different things and you should not confuse them and avoid making them the same.
If you've been mucking around with your variables on your development box to try and replicate how you think XP works, you've been mislead. Please sort out or show what your dev's user environment variables are, we can't help you as accurately as we'd like to as you've left a lot of questions unanswered. On your dev Windows 10 box, the user default location I'm sure should be %SystemDrive%\Users\{username}\AppData\Local\Temp.
How certain are you they have hard-coded c:\Windows\Temp into the code? This is REALLY bad programming for modern Windows, and you should prompt them to change it or it can't be classed at truly XP (or newer) compatible.
Avast does not seem to be the root-cause problem here and I can't imagine how many other compatibility problems your program might run into with other 3rd party apps.
-
The preexisting code has calls to getenv("SystemRoot") then using temp off of there all over the place so Im not going to go back and change where it saves to. None of that is really the issue with this problem since c:\windows\temp shouldnt be getting locked.