Jump to content
Sign in to follow this  
UEZ

Windows 10 build 1803 issue?!?

Recommended Posts

UEZ

What you need is a mapped network share. Just compile the test script and execute it from the network drive.

Test()

Func Test()
    Local $oHTTP = ObjCreate("winhttp.winhttprequest.5.1")
    $oHTTP.Open("GET", "http://www.google.com/", False)
    $oHTTP.Send()
    $oHTTP = Null
    MsgBox(0, "Test", "Executed!")
EndFunc   ;==>GetDateFromINet

 

When I start the script within SciTE from the network drive then it works but when I start the exe from the network then it will crash executing line 7 ($oHTTP.Send()).

Error: The requested action with this object has failed.

 

Can somebody confirm if this is an issue with the latest Windows version (build 1803)? With previous version it works properly.

 

Thanks. :)


Please don't send me any personal message and ask for support! I will not reply!

Selection of finest graphical examples at Codepen.io

The own fart smells best!
Her 'sikim hıyar' diyene bir avuç tuz alıp koşma!
¯\_(ツ)_/¯  ٩(●̮̮̃•̃)۶ ٩(-̮̮̃-̃)۶ૐ

Share this post


Link to post
Share on other sites
UEZ

@Danp2 thanks for your feedback. The odd thing is that it works properly when starting from local disk.

49 minutes ago, Danp2 said:

adding a COM error handler seems to resolve the issue even though the function is never triggered.

Adding an error handler suppresses the error message.

 

I wonder if this is an AutoIt bug or a new Windows 10 security feature...:think:


Please don't send me any personal message and ask for support! I will not reply!

Selection of finest graphical examples at Codepen.io

The own fart smells best!
Her 'sikim hıyar' diyene bir avuç tuz alıp koşma!
¯\_(ツ)_/¯  ٩(●̮̮̃•̃)۶ ٩(-̮̮̃-̃)۶ૐ

Share this post


Link to post
Share on other sites
orbs

Windows has always been indecisive about running executables from network shares (mapped or not). i first encountered this in a domain of Windows XP, where after installing SP2 you had to add the network share as a secure zone. this has been occurring on and off since then. apparently, the MS point of view is that applications should be installed and run locally, and they are immune to the notion that there may be other options. best advice, especially if you are supporting other workstations than your own - swallow the frog, and design your "setup" process so that your compiled script runs from a local hard drive.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.