wraithdu

Contrary to what Microsoft says here about WM_ENDSESSION https://msdn.microsoft.com/en-us/library/windows/desktop/aa376889(v=vs.85).aspx I am not receiving the message on shutdown on any of Windows 7 / 8.1 / 10, if I return TRUE (1) to WM_QUERYENDSESSION. I'm only receiving WM_ENDSESSION if I return FALSE (0) to WM_QUERYENDSESSION. This is rather annoying, as I don't want to halt shutdown, just do some application cleanup. And according to MS, that should be done in WM_ENDSESSION, not the former. For now I can work around this in 1 of 2 ways: 1) If my app has a GUI, do the cleanup in WM_QUERYENDSESSION 2) If my app does not have a GUI (note I must create a hidden GUI to receive the messages), I return FALSE to QUERY and do my cleanup in END. Also note that Windows does NOT display the Cancel shutdown dialog after returning FALSE to QUERY if there is no visible GUI window. See my simple sample code below. Try it with or without displaying the GUI and varying the return of QUERY, and see when and where things are logged. Really I'm just looking for confirmation that MS is full of crap and things don't really work the way they say they should. You can just log out instead of a full shutdown, the result is the same. #include <WinAPISys.au3> #include <WindowsConstants.au3> Global $hGui Global $bExit = False _Main() Func _Main() _WinAPI_SetProcessShutdownParameters(0x3FF) $hGui = GUICreate("") GUIRegisterMsg($WM_QUERYENDSESSION, QUERY) GUIRegisterMsg($WM_ENDSESSION, END) GUISetState(@SW_SHOW) While 1 Sleep(50) If $bExit Then ExitLoop WEnd EndFunc Func QUERY($hWnd, $iMsg, $wParam, $lParam) FileWriteLine(@DesktopDir & "\QUERY.txt", @HOUR & ":" & @MIN & ":" & @SEC & @TAB & _ $hWnd & " : " & $iMsg & " : " & $wParam & " : " & $lParam) Return 1 EndFunc Func END($hWnd, $iMsg, $wParam, $lParam) FileWriteLine(@DesktopDir & "\END.txt", @HOUR & ":" & @MIN & ":" & @SEC & @TAB & _ $hWnd & " : " & $iMsg & " : " & $wParam & " : " & $lParam) $bExit = True Return 0 EndFunc

Weird they would request that, as it's not usually the way it's done. You can't even do this in .NET with standard libraries. PHP has a function to do it, or I found this .NET library someone wrote. You can try to translate it to AutoIt, but I imagine it is quite involved. He had to write his own RSA implementation. http://www.codeproject.com/Articles/38739/RSA-Private-Key-Encryption

Log entry. I'm running the same version of Nod32 7.

Jos, something up with the way the last two versions of the help file EXE have been compiled. ESET NOD32 complains of a trojan or some such nonsense. Do you have it UPX'd or otherwise compressed? Compiler / language?

You may be misunderstanding the point of the script. If you need admin privileges to create files or write to HKLM, why not use the elevated SYSTEM state? Since you already must be an elevated admin to even use this script, you already have the access you're asking for from the launching app. That said... the script takes a security context from explorer.exe for those two functions. Both the _ImpersonateUserStart and _CreateProcessAsUser functions can take a process name as an argument to override that default. You should be able to obtain elevated status if you choose a process that is already running elevated. Now that could be a problem, since there aren't many processes running elevated under a user's account by default. You could use the original app that launched the script, or maybe try to run something that gets automatic elevation like Task Manager. But as I said in the beginning, I don't see the point.

This seems to do. Make sure and choose the option to merge includes. #include <GuiConstantsEx.au3> Opt("GuiOnEventMode", 1) Global $__g_bExit = False Global $g, $b _main() Func _main() $g = GUICreate("test", 200, 100) $b = GUICtrlCreateButton("Exit", 10, 10, 50, 30) SetEvents() GUISetState() While Not $__g_bExit Sleep(100) WEnd EndFunc Func SetEvents() GUICtrlSetOnEvent($b, "_exit") GUISetOnEvent($GUI_EVENT_CLOSE, "_exit") EndFunc Func _exit() $__g_bExit = True EndFunc

Let me see if I can make a quick repro...

I haven't tested this out in quite some time, so thought I'd give it a shot. I found a few problems, albeit in difficult to handle situations. I couldn't find any real guide on how to use this or explanation of any available command line options. The website link in the readme is dead also. Issues: - The @GUI_* macros need to be added to the exclusions - Functions that bind events to user functions using strings need special handling, ie AdLib*, *SetOnEvent, etc. The old Obfuscator.dat file had most of these I think.

This is very cool. Can you explain a bit more about the def_api (well, I think I get this one), def_api_ (with the extra _ ), def_adr, and def_label lines in the .inc file?

I actually just saw that project and have been playing around with it. Very cool! Do you have the source code for these libraries published anywhere that we could take a hand at updating them?

Nicely done. The ControlService function's last parameter is a pointer to a SERVICE_STATUS structure, which it fills in upon error. The correct way to do that would be to create the structure, then pass the pointer to it. The easiest way would be to create an array of 7 dwords, but the best way is to create the actual structure with element names, so you can easily access them later if needed. $tagSERVICE_STATUS = "dword dwServiceType;dword dwCurrentState;dword dwControlsAccepted;dword dwWin32ExitCode; _ dword dwServiceSpecificExitCode;dword dwCheckPoint;dword dwWaitHint" $SERVICE_STATUS = DllStructCreate($tagSERVICE_STATUS) ;; easy way ;$SERVICE_STATUS = DllStructCreate("dword[7]") $ret = DllCall("AdvApi32.dll", "bool", "ControlService", "handle", $hService, "dword", 1, "struct*", $SERVICE_STATUS)

OpenSCManager and OpenService... a 'long' is not a 'handle'. Your return value is wrong, which I already pointed out. I'm sure your CloseServiceHandle calls are also wrong. Read the help file for DllCall, and consult MSDN for the correct function prototypes.

I hope you're up for learning about DllCall and the Win API. I can almost guarantee that this has to do with improvements and bugfixing in DllCall and DllStruct with respect to parameter sizing and alignment in 64-bit windows. To fix this UDF you're going to have to go through the function calls and correct the parameters by referencing the functions on MSDN. Quick example: OpenService Current implementation (read this as <return: param1, param2, ...> etc) <long: long, str, long> Correct implementation ( http://msdn.microsoft.com/en-us/library/windows/desktop/ms684330(v=vs.85).aspx ) <handle: handle, str, dword> Additionally, for functions that have ANSI and Unicode variants, you should explicitly call one or the other. OpenService really calls either OpenServiceA (ANSI) or OpenServiceW (Unicode). This will change whether your DllCall string parameters are ANSI strings (str) or Unicode strings (wstr).

SciTE fears for your sanity?

They are already there. But there has to be something up with the parameters the machine code is expecting. Without the function prototypes however, tough to know.