Sign in to follow this  
Followers 0
cherdeg

[Solved] Problem with shutdown.exe on W2K3 x64

19 posts in this topic

#1 ·  Posted (edited)

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 by cherdeg

Share this post


Link to post
Share on other sites



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


Old Scriptology

Visual Ping 1.8 - Mass Ping Program with export to txt delimited.

Desktop 2 RGB and YMCK - Pick a color in the desktop and get the RGB and YMCK code.

Desktop 2 RGB - Pick a color in the desktop and get the RGB code.

ShootIT 1.0 - Screen Capture full and partial screen

[font="'Arial Black';"]Remember Remember The Fifth of November.[/font]

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

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 by november

Old Scriptology

Visual Ping 1.8 - Mass Ping Program with export to txt delimited.

Desktop 2 RGB and YMCK - Pick a color in the desktop and get the RGB and YMCK code.

Desktop 2 RGB - Pick a color in the desktop and get the RGB code.

ShootIT 1.0 - Screen Capture full and partial screen

[font="'Arial Black';"]Remember Remember The Fifth of November.[/font]

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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? :P

Cheers


Old Scriptology

Visual Ping 1.8 - Mass Ping Program with export to txt delimited.

Desktop 2 RGB and YMCK - Pick a color in the desktop and get the RGB and YMCK code.

Desktop 2 RGB - Pick a color in the desktop and get the RGB code.

ShootIT 1.0 - Screen Capture full and partial screen

[font="'Arial Black';"]Remember Remember The Fifth of November.[/font]

Share this post


Link to post
Share on other sites

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. :P

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!


Old Scriptology

Visual Ping 1.8 - Mass Ping Program with export to txt delimited.

Desktop 2 RGB and YMCK - Pick a color in the desktop and get the RGB and YMCK code.

Desktop 2 RGB - Pick a color in the desktop and get the RGB code.

ShootIT 1.0 - Screen Capture full and partial screen

[font="'Arial Black';"]Remember Remember The Fifth of November.[/font]

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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


Old Scriptology

Visual Ping 1.8 - Mass Ping Program with export to txt delimited.

Desktop 2 RGB and YMCK - Pick a color in the desktop and get the RGB and YMCK code.

Desktop 2 RGB - Pick a color in the desktop and get the RGB code.

ShootIT 1.0 - Screen Capture full and partial screen

[font="'Arial Black';"]Remember Remember The Fifth of November.[/font]

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!


Old Scriptology

Visual Ping 1.8 - Mass Ping Program with export to txt delimited.

Desktop 2 RGB and YMCK - Pick a color in the desktop and get the RGB and YMCK code.

Desktop 2 RGB - Pick a color in the desktop and get the RGB code.

ShootIT 1.0 - Screen Capture full and partial screen

[font="'Arial Black';"]Remember Remember The Fifth of November.[/font]

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

...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.


♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

#17 ·  Posted (edited)

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 - :P - but as an MCSE I probably should have known about this myself. But you never stop learning.

Regards, Chris

Edited by cherdeg

Share this post


Link to post
Share on other sites

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?


♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

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)

I see fascists...

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  
Followers 0