[Solved] Problem with shutdown.exe on W2K3 x64

[cherdeg]

Hi all together,

At the end of one of my tools I call "shutdown.exe" to reboot the system. Using other ways to reboot (e.g. the AutoIt functions or WMI) is forbidden by the company's security policy. I tried the following code:

#RequireAdmin
Run("C:\Windows\system32\shutdown -r -f -t 30", "", @SW_HIDE)oÝ÷ Ù©Ýjëh×6#RequireAdmin
Run(@ComSpec & " /c " & "C:\Windows\system32\shutdown -r -f -t 30", "", @SW_HIDE)

Both versions work no hassle on 2000 (needed to copy the exe from the support tools), XP, Vista, 2008 Server - if the systems are 32bit. On my 64bit test system, exactly it's running "Windows Server 2003 Standard Edition R2 x64", just nothing happens; Run() returns "0" (failure) and sets @error to "1". Does anybody of you have a clue? Me's alone, lost, hungry, thirsty, sick, retarded and desperate.

Regards,

Chris

Edited October 9, 2008 by cherdeg

[November]

Hi all together,

At the end of one of my tools I call "shutdown.exe" to reboot the system. Using other ways to reboot (e.g. the AutoIt functions or WMI) is forbidden by the company's security policy. I tried the following code:

#RequireAdmin
Run("C:\Windows\system32\shutdown -r -f -t 30", "", @SW_HIDE)oÝ÷ Ù©Ýjëh×6#RequireAdmin
Run(@ComSpec & " /c " & "C:\Windows\system32\shutdown -r -f -t 30", "", @SW_HIDE)

Both versions work no hassle on 2000 (needed to copy the exe from the support tools), XP, Vista, 2008 Server - if the systems are 32bit. On my 64bit test system, exactly it's running "Windows Server 2003 Standard Edition R2 x64", just nothing happens; Run() returns "0" (failure) and sets @error to "1". Does anybody of you have a clue? Me's alone, lost, hungry, thirsty, sick, retarded and desperate.

Regards,

Chris

Hi Chris,

I found this http://support.microsoft.com/kb/821287

Check it out!

Cheers

[cherdeg]

Thanks, but...err...nope, that's not it - the KB states the following:

CODE

This problem occurs if an administrator logs on to the server and then locks the computer before Shutdown.exe is invoked. This problem does not occur if the computer is not locked when Shutdown.exe is invoked.

When the computer is locked, you can shut down the computer, if you run the Shutdown.exe command together with the -f option. However, if the computer is locked and if you run the Shutdown.exe command together with the -p and -f options, Shutdown.exe cannot shut down the computer.

Neither the computer is locked nor shutdown.exe is run together with the -p option.

If I issue the same command from a console, it works perfectly smooth.

Anything else?

[November]

Thanks, but...err...nope, that's not it - the KB states the following:

CODE

This problem occurs if an administrator logs on to the server and then locks the computer before Shutdown.exe is invoked. This problem does not occur if the computer is not locked when Shutdown.exe is invoked.

When the computer is locked, you can shut down the computer, if you run the Shutdown.exe command together with the -f option. However, if the computer is locked and if you run the Shutdown.exe command together with the -p and -f options, Shutdown.exe cannot shut down the computer.

Neither the computer is locked nor shutdown.exe is run together with the -p option.

If I issue the same command from a console, it works perfectly smooth.

Anything else?

Hi again,

Are you sure that the shutdown.exe that you are using is suitable for x64?

The error of the run command is 0, so the command was not successeful, try to output the error or execute direct in command line.

Try to use the set path of Windows64x

try also do run command with ShellExecute.

Cheers.

Edited October 8, 2008 by november

[cherdeg]

Are you sure that the shutdown.exe that you are using is suitable for x64?

Try also do run command with ShellExecute.

Hi November,

The system is a freshly installed VMware guest: Yes, I AM sure that it is the right .exe. But are you sure you thoroughly read my posts?

If I issue the same command from a console, it works perfectly smooth.

I will now try a version using ShellExecute, although I do not understand in any way how a Run() could work on one system (32bit) and not on another one (64bit) if them only differ by their bits width.

It would be interesting to have somebody else try to execute my line on his/her Server 2003 x64 - so at least we could assign the problem to my installation (or not).

Regards, Chris

[November]

Hi again,

It's possible that you face a bug in AutoIt.

I made a little program to kill som unwanted java processes and i step into a bug.

Maybe someone is able to give you some more help.

Meanwhile... just a last question... basic one... did you convert the script in x64 mode?

Cheers

[cherdeg]

Hi again,

It's possible that you face a bug in AutoIt.

Meanwhile... just a last question... basic one... did you convert the script in x64 mode?

Cheers

Hi November,

...yes, 10 seconds ago I built an x64 version...and shit: now it works. But separate versions are not in plan. We need one utility for all platforms. NOW I'm really f***ed.

Do you or anybody else know a way how to get an executable for 32 and 64bits?

Would it be possible to add both versions of executable as an resource to a 32bit "loader" which 1st checks the bits and then decides which one to run?

Or is there a way to embed x64 code at certain points within 32bit executable?

[bluelamp]

There is the wonderful Macro @AutoItX64

Here is an example how you could use it:

If @AutoItX64 == 1 Then
    Run("X64Shutdown.exe")
Else
    Run("X86Shutdown.exe")
EndIf

[November]

Hi again,

Create a DOS batch file. I think its the better way to deploy... or... you can think a WMI shutdown...

Cheers and good luck!

[cherdeg]

Hi again,

Create a DOS batch file. I think its the better way to deploy... or... you can think a WMI shutdown...

Cheers and good luck!

Sorry, as I -again- described before...that's no allowed way for me: I am forced to do critical things only and absolutely only by windows command line tools. Calling them by batch: forbidden. Using WMI: forbidden.

[cherdeg]

There is the wonderful Macro @AutoItX64

This maybe wonderful, but is completely useless in my case. The problem is not to call the right version of shutdown, because, the only the version on each local host is to be used.

I need a 32bit executable because I need a single one (1) universal binary that is able to run on 32 AND 64 bit systems. It will be audited, which is an, err, lengthy process. Getting an audit for two versions will be double lengthy, which again is no option. Above all my order is to produce a single one tool.

A way would be to tell the compiler to compile anything between X and Y as 64bit code. Is something like that thinkable?

[November]

Hi again,

I dont see any way out... and compile the script by core design... i don't now... really weird script.

I think Bleulamp idea is the best one... only one script, same program but launched in diferent way.

If you got so many restrinctions... i beliave that a security exception for this cases should be considerated.

Cheers

[cherdeg]

Hi again,

I dont see any way out... and compile the script by core design... i don't now... really weird script.

I think Bleulamp idea is the best one... only one script, same program but launched in diferent way.

If you got so many restrinctions... i beliave that a security exception for this cases should be considerated.

Cheers

Bluelamp's idea doesn't match my case at all: I don't need to find out if I run a 32 or 64 bit compiled binary. What for? I really don't understand. Due to the fact that on the local systems ALWAYS IS the right shutdown.exe, I don't have to differ which one to use. If I want to find out on which version of the OS the script currently runs I use this:

Func _OSBits()
    Local $tOS = DllStructCreate("char[256]")
    Local $aGSWD = DllCall("Kernel32.dll", "int", "GetSystemWow64Directory", "ptr", DllStructGetPtr($tOS), "int", 256)
    If IsArray($aGSWD) And DllStructGetData($tOS, 1) Then Return 64
    Return 32
EndFunc   ;==>_OSBits

And if I want fo find out about the abilities of the cpu in the current system I can use the macro @ProcessorArch.

[November]

Yes i see your issue, but i'm also seeing that is going to be hard to do in AutoIt.

As far as i can see, you what do deploy a single script in all machines to shut down it.

You want a multi processor architecture script to activate shutdow.exe.

Every software that i know have different versions for 32 and 64 bits.

Well mate... i reach out off ideas... good luck for you!

cheers!

[cherdeg]

As far as i can see, you what do deploy a single script in all machines to shut down it.

...if it only was that easy...the shutdown code is only a poky part (~10 lines) of the whole script which consists of about 2500+ lines of code.

The only and main question is: why does "Run()" in the 32bit version start e.g. "netsh.exe" (and many other executables) on a 64bit OS perfectly, but not "shutdown.exe"?

In my eyes there must be an inconsistency. A bug?

[trancexx]

...if it only was that easy...the shutdown code is only a poky part (~10 lines) of the whole script which consists of about 2500+ lines of code.

The only and main question is: why does "Run()" in the 32bit version start e.g. "netsh.exe" (and many other executables) on a 64bit OS perfectly, but not "shutdown.exe"?

In my eyes there must be an inconsistency. A bug?

Read this for answer.

It has very little to do with AutoIt.

[cherdeg]

Read this for answer.

It has very little to do with AutoIt.

Yep, that's it. SHIT.

Edit: Okay, no shit at all but just another case to work off...

$s_cmd = $s_ToolsShare & "\linkd.exe %SystemRoot%\system64 %SystemRoot%\system32"
$i_return_LINKD0 = RunWait(@ComSpec & " /c " & $s_cmd, "", @SW_HIDE)
$s_cmd = "C:\Windows\system64\shutdown -r -f -t 30"
$i_return_SHUTDOWN = Run(@ComSpec & " /c " & $s_cmd, "", @SW_HIDE)
$s_cmd = $s_ToolsShare & "\linkd.exe %SystemRoot%\system64 /d"
$i_return_LINKD1 = Run(@ComSpec & " /c " & $s_cmd, "", @SW_HIDE)

This did it; now it's working. An excerpt from the blog "trancexx" pointed me to:

CODE

Jailed 32-Bit Processes on Windows x64 (Update)

Print Print March 13th, 2008 by Nicholas

The Windows-On-Windows (WoW) subsystem has been included in Windows operating systems to allow for backwards compatibility. It has enabled the execution of 16-bit applications on modern 32-bit based Windows. This abstraction layer is located in user space translating API calls to 64-bit data structures and entry points. This is called API call thunking. Windows x64 Editions include a new variant of the WoW, called WoW64, subsystem thunking API calls for 32-bit applications on the 64-bit kernel.

WoW64 includes several mechanisms to separate file system and registry information for 32-bit applications from 64-bit applications in order to run unchanged on Windows x64. One of the tasks of WoW64 is file system redirection which makes 32-bit tools and libraries available in the expected location: On Windows x64, the 32-bit version of %SystemRoot%\System32 (as found on 32-bit Windows) is relocated to %SystemRoot%\SysWoW64. For 32-bit applications to work properly, WoW64 redirects every access to the new location.

As a very nasty consequence of this design, 32-bit applications are not able to call 64-bit tools located in the original %SystemRoot%\System32 because of the redirection. Fortunately, Microsoft has included most tools in both versions (32- and 64-bit). However, some useful tools are only available in 64-bit versions including shutdown.exe, logoff.exe, msg.exe, tsdiscon.exe and tsshutdn.exe.

All the thanX go to "trancexx" this time - - but as an MCSE I probably should have known about this myself. But you never stop learning.

Regards, Chris

Edited October 9, 2008 by cherdeg

[trancexx]

Let's experiment. Try this.

Compile your script using x64 xersion of Aut2Exe. You will get x64 version.

Then create new script, empty one, no code inside. Add this directives:

#Region 
#AutoIt3Wrapper_outfile=Test.exe
#AutoIt3Wrapper_UseUpx=n
#AutoIt3Wrapper_Run_After="C:\Program Files\AutoIt3\SciTE\AutoIt3Wrapper\ResHacker.exe" -add %out%, %out%, H:\Documents and Settings\trancexx\Desktop\x64.exe, 23, 64, 0
#EndRegion

Compile it to Win32 app and try in on both systems. I'm curious.

You will need ResHacker.exe and change paths from mine to yours in directives.

btw, what happens when you disable the redirection?

[rover]

btw, what happens when you disable the redirection?

help file under section: 'Running the 32-bit version of AutoIt on a x64 System'

DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1)