madasraka Posted March 31, 2010 Posted March 31, 2010 (edited) Simple script run ("C:\Windows\System32\msconfig.exe")is not working External apps used to execute shortcut to msconfig is also not working (external apps such as app launchers) Windows 7 64bit administrator account (administrator account only, no other users created.) Even if i would create launch.bat file with 1 line "C:\Windows\System32\msconfig.exe" and try to execute this batch file from autoit or any other external executor it will fail. What am i doing wrong ?I know there is another way to get to mscomfig is to"C:\Windows\System32\control.exe /name Microsoft.ProgramsAndFeatures" thats for add/remove programs. Is there one to access msconfig ? God why does this have to be so complicated ?Its like i have to click it to prove to it physical interaction and not remote activated or something ? wow. I mean wow this is very secure but annoying sometimes. Edited March 31, 2010 by madasraka
MaxuN Posted March 31, 2010 Posted March 31, 2010 Hi, Try it: Run(RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MSCONFIG.EXE","")) This Script read the real dir from any program (EXE) and run it. See you !!! P.S.: Sorry my english
madasraka Posted March 31, 2010 Author Posted March 31, 2010 well this just compicates the code for 64bit OS caz its going to be Run(RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths\MSCONFIG.EXE","")) But thanks ill try that.
GEOSoft Posted March 31, 2010 Posted March 31, 2010 Since the folder containing that file is generally in the Environment path, have you tried the simple method? ShellExecute("msconfig.exe") George Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.*** The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number. Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else. "Old age and treachery will always overcome youth and skill!"
madasraka Posted April 1, 2010 Author Posted April 1, 2010 windows cannot find "msconfig.exe" Make sure blah blah blah
tehdon Posted April 1, 2010 Posted April 1, 2010 madasraka - can you try the following code ShellExecute("msconfig.exe") While 1 Sleep(100) Wend You'll still receive the error, but check in Task Manager and see if you have AutoIt3_X64.exe or AutoIt3.exe running alongside the AutoIt3Wrapper.exe. If you don't have AutoIt3_X64.exe the application is executing as a 32bit application. From what I'm reading, in 64bit Windows 7, a 32bit application will substitute c:\windows\syswow64\ for c:\windows\system32\ and msconfig.exe only exists in \system32\, not \syswow64\. I have 64bit Windows 7 and can duplicate what you're seeing by running the script from Start > All Programs > Run Script(x86). Scite launches my scripts in x64 mode by default (not sure if that was something I configured during installation or not, I don't recall). As a further test, if you go ahead and compile the above code and check the option to compile for x64, does msconfig launch correctly?
tehdon Posted April 1, 2010 Posted April 1, 2010 Sorry, sources are useful http://msdn.microsoft.com/en-us/library/aa384187.aspx
madasraka Posted April 2, 2010 Author Posted April 2, 2010 (edited) You'll still receive the error, but check in Task Manager and see if you have AutoIt3_X64.exe or AutoIt3.exe running alongside the AutoIt3Wrapper.exe. If you don't have AutoIt3_X64.exe the application is executing as a 32bit application. AutoIt3.exe running REsources refered to 2000/XP i am talking about windows 7 64bit. It would seem to me that any system file has to be executed "physically" kinda like you actually executing it with click or typing a command. If execution is not performed by user but instead by external executor it simply wont work. ShellExecute(@WindowsDir & "\System32\msconfig.exe") ;too look into System32 folder which is correct mscongif location for W7 64bit ShellExecute(@SystemDir & "\msconfig.exe") ;to look into SysWOW64 folder which is not correct W7 mscongif location for W7 64bit is not working. Both say Windows cannot find. Its like file is not there at all, but i am looking at it and see it in System32 folder yet its not being executed. Even if u use old cmd script and execute it by external app, its not working to unless i double click it my self. Its like external executers (autoit script in this case)do not transfer user rights to target of execution thus making the target to be executed under guest privileges or something ? I remember having this issue sense Windows 7RTM version. Thought it would be fixed when official release comes out but it wasn't. Autoit line run (@DesktopDir & "\CMD.bat") CMD line %windir%\system32\mscongif.exe Says : is not recognized as an internal or external command mscongif.exe Says: nothing, it just works but not if executed by autoit or any other external executer. I hope you guys understand what am trying to say. I am sure its a windows 7 feature or a bug that has to be resolved. BTW i just tested this on XP SP3 and it didnt work to New cmd script on desktop with 1 line msconfig does not start msconfig like Windows 7 does. This is so strange. i just need a shortcut to msconfig that can be executed by external source. I cant right click on msconfig.exe and select to create shortcut to desktop because that shortcut will not work if executed by external application. I tried everything and getting tired Edited April 2, 2010 by madasraka
GEOSoft Posted April 2, 2010 Posted April 2, 2010 CMD line %windir%\system32\mscongif.exe Says : is not recognized as an internal or external command mscongif.exe Says: nothing, it just works but not if executed by autoit or any other external executer. If those were copy/pasted into this post then it's not overly surprising that they don't work. Hint: TYPO Try this and see what happens, I can't test it but it could be the solution. $sOldPath = EnvGet("Path") $sAddPath = @WindowsDir & "\System32" If NOT StringRegExp($sOldPath, "(?i);?(" & $sAddPath & "\\?)(?:;|$)" Then EnvSet("Path", $sOldPath & ";" & $sAddPath & "\") ShellExecute("msconfig.exe") EnvSet("Path", $sOldPath) You can probably use ShellExecute(@WindowsDir & "\System32\msconfig.exe") just as easily if not easier. George Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.*** The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number. Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else. "Old age and treachery will always overcome youth and skill!"
Hellooopsforgotsendcommand Posted April 2, 2010 Posted April 2, 2010 This works for me on Xp ShellExecute("C:\WINDOWS\pchealth\helpctr\binaries\msconfig.exe")
madasraka Posted April 2, 2010 Author Posted April 2, 2010 C:\Users\Administrator\Desktop\New AutoIt v3 Script.au3(3,70) : ERROR: syntax error and ShellExecute("C:\WINDOWS\pchealth\helpctr\binaries\msconfig.exe") Windows cannot find ..... make sure blah blah.this is not windows XP. XP is totaly different from W7 in terms of execution. This is windows 7 execution issue that i cant solve no matter what i try. I just cant execute msconfing anyway i try and am sure there are more executable's that i will not be able to execute it that will be acting strange if not executed by clicking. In fact i have tested this on one of the cracked projects i downloaded from net where it would act strange unless executed physically or by clicking on it 2 times. I have a feeling windows 7 restricting any remote executions regardless of executors rights. So strange but its true. anyone here actualy has windows 7 to confirm my issue ? I ask because your responses sound like you didnt even try to do it your self or have XP which in this case is far to different. I am XP fan my self but when i tried W7 i dont want to go back, and why if everything works fine ? Anyway thanks guys for trying.
tehdon Posted April 3, 2010 Posted April 3, 2010 As stated previously, I am running Windows 7 x64 and ShellExecute() does work to launch msconfig.exe IF I am using the x64 version of AutoIt, otherwise I receive the same error. The previous link I posted was an excerpt from the Programming Guide for 64-bit Windows on File System Redirector. In it, the following is stated In most cases, whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to %windir%\SysWOW64 I believe this means that even if your script specifically references 'c:\windows\system32\', if Windows sees that your are an x86 application, it will redirect you to 'c:\windows\syswow64\'. The help file topic 'Running under Windows 64-bit Edition' discusses this topic as well. In it, it is suggested the following will disable the redirector DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1) It may be worth adding the above to your script and seeing if msconfig can suddenly be opened properly.
madasraka Posted April 3, 2010 Author Posted April 3, 2010 thanks for helpful info.Disabling redirection worked, but this is so stupid when it comes to apps executing cmd lines that are just as specific about paths.Man this comes with so many problems, for example ShellExecute(@WindowsDir & "\System32\msconfig.exe") might not work for all 64bit OS such as XP and VistaThis is so confusing man my head hurts LOLI hope next version of windows will change its 64bit behavior to something likeKeep old 32bit apps in program files but instead point 64bit to program files(x64)This way if next windows generation 128bit will arrive, it could just use new program files(x128) instead of having to change everything around. Same with registry local keys, just as confusing.
spymare Posted January 10, 2011 Posted January 10, 2011 this should work but it doesen't:#include <Process.au3>$rc = _RunDos("start msconfig.exe")when you type into cmd: start msconfig.exe it work fine, but not with auoits inbuild "Rundos" function..
Juvigy Posted January 10, 2011 Posted January 10, 2011 You may be UAC-ed. Try #requireadmin in the beginning
ripdad Posted January 10, 2011 Posted January 10, 2011 Lets play Hide and Seek on Win7 #RequireAdmin MsgBox(0,'',FileExists(@SystemDir & '\msconfig.exe')) MsgBox(0,'',FileExists('C:\Windows\System32\msconfig.exe')) MsgBox(0,'',FileExists(@WindowsDir & '\System32\msconfig.exe')) MsgBox(0,'',FileExists(@WindowsDir & '\SysWow64\msconfig.exe')) Nope, not anywhere in those! Where could it be? Doing a search (using Windows Search) reveals it's here: C:\Windows\System32\msconfig.exe But, I guess thats just a ghost. So, open the "containing folder" and copy "msconfig.exe" to the Desktop. Now lets double-click it! What? Huh? I heard it said that Win7 is quote: "Light Years ahead of WinXp" That reminds me of an old '70s comic strip that said: "Man ... I used to know this cat ... he was soooo far out ... he never came back." "The mediocre teacher tells. The Good teacher explains. The superior teacher demonstrates. The great teacher inspires." -William Arthur Ward
Sonny Posted January 16, 2011 Posted January 16, 2011 KISS FileWrite(@ScriptDir & "\cmd\runmsconfig.bat", '@echo off' & @CRLF & 'start msconfig') sleep(500) Run(@ScriptDir & "\cmd\runmsconfig.bat", @ScriptDir) [font=arial, helvetica, sans-serif][quote]For every rule there's three ways around it.[/quote][/font]
Richard Robertson Posted January 17, 2011 Posted January 17, 2011 Why do you want to start msconfig anyway? It doesn't do anything that AutoIt cannot already do.
Sonny Posted January 17, 2011 Posted January 17, 2011 Richard, Starting msconfig from GUI is definitely needed in Win 7 to restart the computer in Safe Mode. I personally use the GUI as a remote tool which gets sent to the clients PC. I am unable to press f8 on reboot, hence the need for msconfig. If you know of a way to reboot into Safe Mode using Autoit scripts, please share. Sonny [font=arial, helvetica, sans-serif][quote]For every rule there's three ways around it.[/quote][/font]
Moderators SmOke_N Posted January 17, 2011 Moderators Posted January 17, 2011 thanks for helpful info. Disabling redirection worked, but this is so stupid when it comes to apps executing cmd lines that are just as specific about paths. Man this comes with so many problems, for example ShellExecute(@WindowsDir & "\System32\msconfig.exe") might not work for all 64bit OS such as XP and Vista This is so confusing man my head hurts LOL I hope next version of windows will change its 64bit behavior to something like Keep old 32bit apps in program files but instead point 64bit to program files(x64) This way if next windows generation 128bit will arrive, it could just use new program files(x128) instead of having to change everything around. Same with registry local keys, just as confusing. Things are only as confusing as you let them be. __Run("msconfig.exe") Func __Run($s_program, $s_workdir = "", $i_show = @SW_SHOW, $i_opt_flag = 0) If @OSArch = "X86" Then Return Run($s_program, $s_workdir, $i_show, $i_opt_flag) EndIf Local $t_int = DllStructCreate("int") Local $p_int = DllStructGetPtr($t_int) DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "ptr", $p_int) Local $i_pid = Run($s_program, $s_workdir, $i_show, $i_opt_flag) DllCall("kernel32.dll", "int", "Wow64RevertWow64FsRedirection", "ptr", $p_int) Return $i_pid EndFunc Instead of "Run()" ... just use this __Run(). Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now