Windows 10 Autorun Doesn't

Windows 10 version: 20H2 with all current uppdates.
I have a USB flash drive labelled TravelDrive that contains the Autorun.inf file constructed using existing documentation that contains:

[AutoRun] OPEN=C:\Program Files\Notepad++\notepad++.exe G:\Personal\CC.txt ShellExectutive=C:\Program Files\Notepad++\notepad++.exe
UseAutoPlay=1 LABEL=TravelDrive ACTION=Start My Application

That I expect will launch the program: C:\Program Files\Notepad++\notepad++.exe that wil open the file: G:\Personal\CC.txt.located on the flash drive labelled: TravelDrive (G:\).
When I engage/insert the flash drive into the USB port I am provided the Autorun notification, but NOTHING else happens!
So now what?

Lairbear (Randy Reist)

DalChina--

Thanks for the quick response. Unfortunately, no luck...

I downloaded, and installed the software.

Inserted the flash drive.

Nothing happened- not even a notification. Further thoughts ?

So what's the weather like in the U.K. Absolutely gorgeous here in Pennsylvania!!!! 85 degrees farenheit, and nary a cloud in the sky !!!

Randy

OK, color me ignorant and/or naieve, but please elaberate on your point b that reads:
b. the portable program on the flash drive you wish to run?

- - - Updated - - -

... Continued

Would you kindly elaborate the meaning of portable program?

Are you saying that Notepad++.exe is


- - - Updated - - -


... Continued; one more time...

Would you kindly elaborate the meaning of portable program?

Are you saying that Notepad++.exe is required to exist on the USB flash drive?

R

dalchina--

Thanks much for your direction. My problem was centered upon my attempt to launch my program on my C: drive, rather than launching it on my USB flash drive (G:). Once changed, autorun runs successfully when the USB flash drive is engaged/inserted.

Closing this thred.

Dalchina--
If I may add a few words in wrapping-up...
I find that Microsoft's implementation of Autorun to be overly restrictive. Such restrictions are an outgrowth of their even weaker implementation of general, overall system security; which is woefully vulnerable. Firstly, one should not be able to change a file extent so that you can manipulate a file in a different method (EXE to TXT, etc.)! Once a file's 'type' is established (by its creating software), it should be stored in a hidden location within the file's disk header (MFT), and thus changing its file name extent has NO effect upon how it's to be manipulated. This is ONLY one of many intrinsic security vulnerablities within Microsoft's OS (Windows kernel). ONLY a compiler, OS kernel, or an identified system software utility may change the contents of an object code file.
Secondly, the Intel processor design should NEVER allow any (non-OS) software to access memory outside of an array (vector) at either end of the vector. Additionally, any non-OS kernel program should not be allowed to directly access core/main memory (or disk file data) by simply reading/writing via an absolute memory/disk address!. The system that I supported for almost 40 years would not allow any of the above to occur, and would result in the immediate termination of the program(s) attempting such actions.
Let me now step down from my soap box !!!!
Randy