[Solved] Can't run Sysprep in Windows 8 RP

[Tripredacus]

It doesn't seem that I can run Sysprep in Windows 8 RP x64 using @ComSpec. I have no problem running other apps using either Run() or RunWait() in the same app. I am testing in Audit Mode (Administrator account, UAC is disabled). I already searched the forums and didn't find any one else trying to execute Sysprep like this...

This does not work when run compiled:

Run ( @ComSpec & " /c c:\windows\system32\sysprep\sysprep.exe /oobe /shutdown")

Returns error "is not recognized as an internal or external command, operable program or batch file." I don't know how to keep the ComSpec window open, so the only way for me to see this was to hold down the Enter key so I could see the error. Curiously, running this manually works fine:

cmd.exe /c c:\windows\system32\sysprep\sysprep.exe /oobe /shutdown

App is compiled for x86.

OH! Do not try to run this on your workstation!!!

Edited June 20, 2012 by Tripredacus

[BrewManNH]

Compile it for x64 and see if that works, on a 64bit OS the system32 folder isn't always system32 depending upon what program you're trying to run.

BTW, use /k instead of /c to keep the window open.

[Tripredacus]

I added MsgBox to show me the @ComSpec value for both an x86 and x64 compiled EXE, but the path is the same. Interestingly enough, the x86 compiled app (using /k) shows me:

'C:\Windows\System32\sysprepsysprep.exe' is not recognized as an internal or external command, operable program or batch file.

However, if I run the x64 app, it actually runs! Unfortunately, I'll have to experiment as I need to get this app to run in 32bit.

Update: Using ShellExecuteWait generates a not found error as well.

I can confirm the path with the run box:

I will run a procmon trace on my test app to see where it is actually looking.

Update2: Even though I am fully qualifying the path to the exe I want to run, Procmon reveals that it is looking for C:Windowssyswow64sysprep.exe...

FWIW, this isn't the first time I've run into this problem of apps looking in the wrong folder for files. Although I can't go into details, another program I was testing uses a DLL. I had it in the same folder as the EXE, but it would only look for it in SysWow64. Since AutoIT was not involved with that particular problem, I imagine this is either a bug or a "feature" in Windows 8.

Edited June 20, 2012 by Tripredacus

[BrewManNH]

In a 64 bit operating system, the system32 folder calls are redirected to the C:WindowsSysWOW64 folder when an x86 program is being run, there's no sysprep.exe in the C:WindowsSysWOW64sysprep folder so the program fails. In the help file is a workaround, quoted below.

Can't quote what I want to quote because the forum is messing up the formatting. In the help file, under Using Autoit, look for the heading "Running under Windows 64-bit Edition" for the work around.

Edited June 20, 2012 by BrewManNH

[Tripredacus]

I found this is caused by File System Redirection. When a 32bit application wants to access the System32 folder on a 64bit OS, Windows 8 will default any paths to syswow64 on the idea that a 32bit program would really be looking for the 32bit files. NO!

Anyways, I found a "secret" folder we can use in place of system32 that allows 32bit apps to access the correct folder.

ShellExecuteWait ("c:windowssysnativesysprepsysprep.exe", "/oobe /shutdown")

Answer using the "sysnative" dir instead of "system32":

http://social.technet.microsoft.com/Forums/lt/ITCG/thread/28974b59-1b79-44fd-8bb2-a0a412e18862

Alternatively, for other problems not directly relating to accessing the System32 folder, but still relating to File System Redirection, there are two calls that can be made to disable and then re-enable it.

Wow64DisableWow64FsRedirection function