Windows 10 blocks .exe

3

0

I have a Windows 10 Pro machine (version 10.0.18362) and an executable file test.exe I created myself.

The executable runs fine from a cmd terminal on other Windows machines (including other Windows 10 Pro machines), but not on this one. There is no error, no output, nothing. A new prompt simply appears underneath in the cmd terminal, with nothing in between. This is the puzzling part.

Why does Windows refuse to run the executable, or show any error? How can I "unblock" it and make it run?

I tried Googling for this problem, and found suggestions such as (e.g. here or here):

  • disable Defender and firewall (didn't help)
  • edit Group Policy Settings and run cmd as administrator (didn't help), or
  • edit registry (didn't help)

Any other ideas?

test.exe was created by running pyinstaller --onefile test.py on the following (trivial) Python 3.7 program:

print("Success")

Again, the same executable works fine on other Windows machines.

There is no firewall, antivirus, defender or shield running. I am running the correct executable in the correct directory.

EDIT: just found another clue: The same executable works if run from a pen drive. It doesn't work when run from the C: drive.

What settings or process could possibly be causing this?

user124114

Posted 2019-10-29T12:47:21.910

Reputation: 473

Comments are not for extended discussion; this conversation has been moved to chat.

– DavidPostill – 2019-10-30T20:23:22.427

"The same executable works if run from a pen drive" : Does the folder on the pen drive contain more software files than were copied to the disk? – harrymc – 2019-11-19T11:29:49.850

did you run in from a cmd that was executed as administrator (when it's stored in C:\)? Is it actually in the root folder of the C-drive or in a subfolder? – Albin – 2019-11-21T13:19:23.917

1Have you tried to check the Windows Event Logger if there is an error or warning that can help you to understand what's happening? – Denis Cappellin – 2019-11-24T10:40:13.943

Run Process Monitor and see if it gives you any clues.

– pholcroft – 2019-11-25T10:25:33.040

@Albin I ran it both as administrator and not; makes no difference. – user124114 – 2019-11-26T22:53:16.773

@harrymc it doesn't. – user124114 – 2019-11-26T22:53:57.833

Answers

0

Perhaps try adding --win-private-assemblies so that it won't try using newer libraries that may be on this particular system:

Any Shared Assemblies bundled into the application will be changed into Private Assemblies. This means the exact versions of these assemblies will always be used, and any newer versions installed on user machines at the system level will be ignored.

Also, make sure you're not actually running from the root of C:\ or some other protected area.

Louis

Posted 2019-10-29T12:47:21.910

Reputation: 18 859

Can you expand on that make sure you're not actually running from the root of C:\ or some other protected area? What's that? – user124114 – 2019-11-20T08:21:38.657

Sorry for not referencing this, but I believe unelevated programs can't write files to C:\ and other protected areas, like systems folders or even Program Files. They are allowed to create directories in C:\, however. – Louis – 2019-11-21T02:31:48.237

There's no writing going on, so that doesn't seem relevant. – user124114 – 2019-11-21T08:36:19.133

Asked: 2019-10-29T12:47:21.910

Viewed: 155 times

Active: 2019-11-19T10:52:01.487