After being infected with a virus or incorrectly changing the system registry, the user may encounter the fact that executable EXE-files (installation MSI-files or PowerShell/CMD/VBScript files) not opening in Windows. When you run any program (shortcut) from File Explorer, nothing happens, a window appears asking you to select a program or all EXE files are opened in a different program (for example, in notepad.exe or in paint.exe). In this article, we will look at how to fix the problem when you cannot run any executable file or application on Windows.

How to Fix Broken EXE File Associations on Windows?

When you run any application *.exe file in Windows, a window appears asking you to select a program (How do you want to open this file?):

Or errors appear:

This file does not have an app associated with it for performing this action. Please install an app, if one is already installed, create an association in the Defaults Apps Settings page.

Windows cannot access the specified device, path, or file. You may have the appropriate permissions to access the item.

Windows can't open this file.

Most often, this problem appears after a virus infection or an unsuccessful attempt to “optimize” the Windows registry. The source of this problem is that the file associations for *.exe files were reset in the Windows registry. To restore associations for executable files on Windows, you need to use the Registry Editor (regedit.exe), but it also won’t open because it is also an executable file. Neither cmd.exe nor PowerShell opens. What to do in this case?

1. Create a simple text file on your desktop;
2. Paste the following line to the file: start cmd
3. Rename the file to run.bat;
4. Right-click on the file and select Run as administrator;
5. Confirm the elevation of privileges in UAC and an elevated command prompt window will open;
6. You can run regedit.exe and make changes to the registry manually (the method is described below) or paste the following code into the command prompt window:
   reg delete HKEY_CLASSES_ROOT\.exe /ve /f
reg add HKEY_CLASSES_ROOT\.exe /ve /d exefile /f
reg delete HKEY_CLASSES_ROOT\exefile /ve /f
reg add HKEY_CLASSES_ROOT\exefile /ve /d Application /f
reg delete HKEY_CLASSES_ROOT\exefile\shell\open\command /ve /f
reg add HKEY_CLASSES_ROOT\exefile\shell\open\command /f /ve /d "\"%1\" %*\"
assoc .exe=exefile
   
7. These commands will reset the EXE file associations to the default ones;
8. Restart your computer and try to run any app.

If even the *.bat and *.cmd files won’t start on your computer, you will have to edit the registry manually in Safe Mode.

1. Boot the computer into the Safe Mode (just interrupt Windows boot by pressing the power button three times in a row);
2. The computer will boot into the Windows Recovery Environment (WinRE). Select Troubleshoot -> Advanced options -> Startup Settings -> Restart. Press F4 to boot Windows in Safe Mode;
3. Run the Registry Editor (regedit.exe) and go to the reg key HKEY_CLASSES_ROOT\.exe;
4. Change the Default registry parameter value to exefile;
5. Then go to the HKEY_CLASSES_ROOT\exefile\shell\open\command and change the value of the Default parameter to "%1" %*
6. Then, by analogy, change the values of the Default parameter to "%1" %* in the ?HKCR\exefile\shell\open and HKCR\exefile registry keys;
7. Restart your computer normally. File Explorer should now use the default EXE file associations. Try to run any *.exe file.

Additionally, you should check these steps to restore *.exe file associations:

• Execute the command to reset the EXE file associations: assoc .exe=exefile
• Check that the UserChoice key is missing in the registry key HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.exe. If there is such a key, delete it;
• Check the integrity of the Windows image and system files using the commands:
  sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
• Make sure that your anti-virus program doesn’t block the launch of executable files;
• If Windows displays a security warning when opening executable files, follow the instructions in this article.

Windows Cannot Run EXE Files from a Network Share

If users can run EXE files locally on their computers, but an error appears when launching files from network shared folders, then the cause of the problem may be different.

1. Check the current NTFS permissions for the shared folder or file. If the user is not assigned NTFS Read/Execute permission, then an error will appear when running the executable file:

   Windows cannot access \\server1\sharedfolder\file.exe. You do not have permission to access applicatin.exe file.

   

   Change NTFS permissions manually or through PowerShell.
   

2. Try running the executable file in compatibility mode. To do this, open the properties of the EXE file, go to the Compatibility tab, select the compatibility mode with Windows 8. Try to run the application from a network share.

The problem may be related to the fact that you are trying to connect to a shared folder located on a device that only supports the SMB v1 protocol (this could be a NAS storage device, a file server with a legacy OS version, such as Windows XP or Windows Server 2003).

Errors may indicate this:

The application was unable to start correctly (0xc00000ba)

Exception thrown at 0x00007FFA2B86624E

0xC0000005: Access violation reading location 0x0000000000000000)

Check if SMBv2 or SMBv3 is enabled on your file server using the PowerShell command:

Get-SmbServerConfiguration | Select EnableSMB2Protocol

If SMBv2 is disabled, you can enable it:

Set-SmbServerConfiguration -EnableSMB2Protocol $true

Also, if you are using Linux Samba as a file server, you can disable SMB1 in the configuration file smb.conf. Add the line min protocol = SMB2 to the [global] section and restart Samba.

By default, you cannot access shared folders hosted on a file server running Windows Server 2003 or on a NAS device that only supports SMB1. To access such an SMB share from modern Windows 10 builds, you need to enable the SMB 1.0/CIFS Client on users’ computers (which is not recommended for security reasons).

The correct solution, in this case, is to migrate the shares with executable files to Windows Server 2012 R2/2016/2019, where the SMB1 protocol is disabled. In this case, you will be able to run executable files located in shared folders from your Windows 10 device.