Again confused with declares


The declares I’m trying these days are failing, and it looks like I need advices.
Currently, I have this code:

Declare Function GetLastError lib "Kernel32" () as Int32

Declare Function WTSGetActiveConsoleSessionId lib "kernel32" () As int32
Declare Function WTSQueryUserToken lib "Wtsapi32" (SessionId As UInteger, ByRef phToken As Ptr) As Boolean
Declare Function CloseHandle lib "kernel32" (hObject As Ptr) as Boolean

Declare Function CreateProcessAsUserW lib "advapi32" (hToken As Ptr, _
lpApplicationName As CString, _
lpCommandLine As Ptr, _
lpProcessAttributes As Ptr, _
lpThreadAttributes As Ptr, _
bInheritHandles As Boolean, _
dwCreationFlags As UInteger, _
lpEnvironment As Ptr, _
lpCurrentDirectory As CString, _
lpStartupInfo As StartupInfo, _
ByRef lpProcessInformation As ProcessInformation) As Boolean

Var acsid as int32=WTSGetActiveConsoleSessionId

Var UserTokenHandle As Ptr
Var rslt As Boolean=WTSQueryUserToken(acsid,UserTokenHandle)
var err as Int32=GetLastError

Var ProcInfo As ProcessInformation
Var StartInfo As StartupInfo

rslt=CreateProcessAsUserW(UserTokenHandle, "C:\Windows\System32\cmd.exe", nil, nil, nil, False, 0, nil, nil, StartInfo, ProcInfo)
If UserTokenHandle<>nil Then rslt=CloseHandle(UserTokenHandle)

In my tests, acsid equals 1, so I guess this line works.
The next statement (Var rslt As Boolean=WTSQueryUserToken(acsid,UserTokenHandle)) already seems to be a problem. rslt equals false and UserTokenHandle is empty.
However, I’ve purposely added the GetLastError line just after, and I’m getting 0, presumably meaning no error was encountered… Confused.

Can anyone help, please?

Can you post a little demo project with your StartupInfo struct in too and I’ll take a look.

Oh, sorry. Of course.
I thought about it while writing the message and then forgot… These structures are rather mandatory :sweat_smile:

I just put it on my server:

Also putting the struct right here:


I’ve corrected everything (I don’t know if you know about [LINK REMOVED PER OP REQUEST]) and have it returning a UserTokenHandle. You will need to Run Paused and install and run the paused exe as a service to get it to return that as WTSQueryUserToken mentions

To call this function successfully, the calling application must be running within the context of the LocalSystem account and have the SE_TCB_NAME privilege.

You will need to do the impersonation as CreateProcessAsUserW will need TOKEN_QUERY, TOKEN_DUPLICATE, and TOKEN_ASSIGN_PRIMARY, are you ok playing around with that or do you want me to write it?



I didn’t, but I’ll check that soon. Looks like a very interesting piece of information.

I was confused by these accounts. I assumed a “LocalSystem” account meant a base account for any user’s account. As you can see, I’m not a deep Windows guy.

I’ll first try myself, as a way to learn; thank you.
And I bet your corrections will also put me on the right tracks.

A big thanks!

No worries, that test is running in 32bit by the way, I’ve yet to test it for 64bit as the structures will need padding due to xojo bugs. I’m just looking at that now, but I think I’ve found another bug which I’m looking into.

That’s a great piece of information I would have loved to know before, actually. Each time I started a new project involving declares, I had to search on various websites for what a DWORD (or others) meant in Xojo; that was a pain and your article above is now in my favourites references links :wink:

Ah, good to know. I have a VM with a 32bit Windows 10 OS, fortunately.

Another thing I was unaware of.

A serious one?

Thank you.

50/50, it makes everything more awkward and more verbose, I’m just working on the demo projects now.


haha I need to go back to sleep, I was using the checkbox for desktop and not console, hahah, brilliant

We’re so accustomed to seeing a lot of bugs in Xojo…

Project updated with 32 and 64 bit structures (all checked against visual studio), they are selected automatically by Include In under the gear tab in the inspector.

This is needed because of structure alignment issues in 64bit (<>), its a 4-5 year old compiler bug, but I guess it’s not that important as not enough of xojo’s citizen developers encounter it /shrug

Let me know if you get stuck.

1 Like

Thanks a lot for all this.

While I understand that bugs hitting many developers are more important to fix than those concerning only a few, I think bugs that can be quickly fixed (even if not impacting a lot of users) are also worth getting attention.
I feel, as Xojo handles that now (i.e. focusing on bugs that impact widely), once quick-to-fix&impacting bugs have been handled, they focus on the other impacting ones (that means, hard-to-fix&impacting bugs). A shame, because there are “plenty” easy-to-fix bugs, albeit probably not impacting the majority of users, that don’t get attention, with this method.