The setup process in windows fails access denied w

I just can't install the software (in Windows 10), have somebody else handled this issue?

Security Software Interference (False Positive Detection)

Is that just an access denied warning? It looks like it might be a security software issue - the folder is being recognized as malware. This problem is more and more prevalent as security software tightens security for today's conditions: https://github.com/Microsoft/vscode/issues/13559

Disable your anti-virus or security software and try again. If that doesn't work, please read some further suggestions below.

Please report what security software caused the problem for you - if any. This is important for the community. We are seeing more and more of these problems, and they can be very mysterious at first.

WARNING: Please note that certain security software may quarantine whole MSI files directly from the super-hidden, local cache folder these days! When this happens you really have a problem. Please read section 7 in this answer for information: How do I avoid triggering MSI self-repair with my WiX / MSI package? (don't be deceived by the question name - section 7 is relevant). You may be stuck with an un-uninstallable and un-upgradeable package.

Some Rules of Thumb For Deployment Debugging

Deployment problems tend to center around: something is locking resources (in use), something is blocking / preventing access (security software intervention, network unreachable), something is denying permission (ACL, privileges), something is corrupted (data file, OS settings), a runtime requirement is not met (missing dependencies).

Please consider these easy, general measures to minimize problems:

Core

Try a failed installer on a clean system (virtual machine) before trying anything else.
Definitely shut down security software and anti-virus if you see deployment problems.
Shut down as many applications and software solutions as possible before installing.
Verify that the target disk has enough free space available (a more common problem than expected with today's laptop SD-disks and huge media files).
If your localized installer fails, is there an English version available?

Further

Make sure there are no remote users logged on or accessing shared resources.
Verify the integrity of your downloaded installer file - if possible.
Check the target installation disk for file system or surface errors.
Do a malware check prior to deployment (if previous deployment failed).
Check for custom permissions (ACL) in target location for a failed install.

Other Potential Causes of Setup Failure

Potential causes of setup failures that I can think of right now center around locking issues, connectivity issue, data corruption issues, system settings interference and various obscurities. This list is a bit mad - especially towards the end - it is just a brain dump.

There is a lock on the folder by a running tool on the box (Visual Studio?). Close down suspects and try again. Or network connectivity could be lost if installing to a network drive (don't).
- As stated above the lock in your case is probably from a security software blocking your installer as it tries to create a folder recognized as malware (false positive - probably).
- Other tools could also be at fault, including scheduled tasks in Windows or development tools or similarly "involved" or "advanced" software. Or regular, simple software for that matter (but what would those be doing so deep in the folder structure?). Windows services can also interfere. Many possibilities.
- I suppose you could be installing to a network drive, and connectivity could be lost.
- I suppose you could be installing into a folder that is shared, and someone on the network may have a lock on a file your installer is trying to replace.
- I suppose a folder could be encrypted somehow, and not decrypted and available for writing? (I don't use this feature - also, it would be weird to encrypt an installation directory.
- Since we are out on a limb already, how about if a user is connected by remote desktop and has a lock in the target folder?
- A domain admin could be working on your local disk at any time, locking resources without any visible trace for you.
The installer file itself is corrupt (incompletely downloaded - or even meddled with by a security software quarantining stuff directly from the embedded or extracted CAB or ZIP file - in this case you must download the software again and retry - all the while with your security software disabled the whole time - which might not be allowed by company policy).
- Besides incomplete download and security software interference other things can also cause the file to become corrupt. Real malware for one thing, network connectivity issues, bugs in SAMBA (Linux / Windows file sharing technology) or other relevant tools (decompressors etc...), and many other, more obscure reasons, etc...
- Even hardware issues such as bad drivers for cutting edge I/O components such as super fast NVMe disks. No end to grief the latter can cause you. And there is the issue of flash drive wear and exhaustion.
- If you can, check your download with Virustotal.com. You may already know that your own security software detects the setup as malware, see if other security software agree? This is general advice for unknown installers - your installer is probably fine.
- The file may be too large to upload to Virustotal.com (or other online malware scanners). You can also use procexp64.exe from Sysinternals to check running processes for malware interactively (direct download of Sysinternals Process Explorer) to scan all your running processes after test installation. See some suggested usage steps for the tool here.
Your Windows installation is corrupt for whatever reason.
- This could be real malware having destroyed something. I doubt it in your case.
- It could be your own tinkering and testing of various Windows settings and configurations.
  - You could have set some deny ACLs to lock folders for someone, and they have a lot of side-effects.
  - I know next to nothing about group policy, but it has a serious amount of settings that have impact on workstations and servers alike.
- Maybe you installed some pre-release alpha / beta stuff that has messed up the target destination or changed the folder's ACL (permissions).
  - You could check what is up with that folder - just renaming it adding an _OLD suffix to its name and then try to run again.
  - Or run a test install on a virtual machine perhaps - if you got one - to see if it finishes on a clean machine.
- There is an error in the file system or physically on the disk. The target file's disk sector is corrupt - it may even have physical damage.
I'll list some more obscure causes of installation failures - since we are at it.
- It might be rare (for desktops), but it is possible that the target disk or partition is full (not so rare for laptops?).
- Believe it or not, but the installer target path can be too long! I don't think such a setup would get off the ground if this was the case, but maybe (Windows Installer would probably fail before file copy starts).
- It is not impossible that a custom action or custom operation may be happening in your setup at the point of failure where code or logic is running that suffers missing runtime dependencies. Not likely in this case I think.
  - For example: the .NET runtime may be broken or missing for an installer managed code custom action or operation.
  - Could Code Access Security also fail for managed code embedded in the setup? Frankly I am not sure - in MSI most custom actions run elevated.
- Localized (translated) installers sometimes have weird problems. This could be the case for you. Localized setups are often not tested and UAT'd as much as English setups are. Weird problems may result.
- I should add that the target OS may be unsupported or unsuitable for deployment of the package in question. Not at all likely in your scenario I would say, these are just obscure, potential causes of failure. If this would be the case, the setup would normally refuse to run at all, not fail mid-install.
  - Certain server OS machines may have problems installing certain setups.
  - Server machines with special roles (AD domain controller,
  - Virtualized servers, terminal servers, thin clients, etc...
- The installer suddenly does "something illegal" - it is badly designed and it suddenly shows intermittently on some systems.
  - You are running an un-elevated installation operation and the setup suddenly tries to write to a protected location.
  - The target folder is "something weird" - like a hard or soft link. Now this I have never seen, just listing whatever comes to mind.
  - Your installer is elevated, but suddenly tries to write to a very protected system location in an illegal way (GAC, WinSxS, etc...) (can happen on some systems for various reasons - for example a system in a different language due to errors in the installer).
- I think that is as obscure as I want to go. There are certainly more possibilities.
  - I have seen a couple of installers that demanded to chat over the Internet and failed when that was not possible.
  - You are installing into a folder with a Unicode name (Japanese, Korean, Chinese, Arabic, etc...), and the installer fails to complete correctly due to bugs in the setup.
  - Could Windows Search be running and causing problems with locks or bugs? (getting ridiculous yes, but let's indulge this interrogative mood).
  - I guess various version control systems could maintain unexpected locks in the file system. As could Internet file sharing solutions or web servers (?).
  - I suppose custom configuration for NT privileges could cause certain operations in a setup to lock up and be unable to complete. Some info in section 13 here: How do I avoid common design flaws in my WiX / MSI deployment solution?.
  - And worse and worse: the system time is wrong during installation and the setup halts because of it? (can certainly happen with Windows Update). Perhaps you even switched to a different time zone during the install and something crashed or got confused. Never seen this. Perhaps you are mid-Atlantic in a 777 installing Visual Studio Code (this shows other issues - just sayin') whilst refusing to speak to the weirdo next to you . Hint: chances are you might be the weirdo in such a scenario :-).
  - The issues are so obscure now that it is time to end the list. The point is just this: installers are terribly vulnerable to a lot of things that we hardly ever think about. Luckily things seem to work most of the time - making it all the more clunky to work things out when problems result. With that said, some of these latter points may border on the verge of being ridiculous. But don't underestimate "the resident evil in all things computing".