WIL Extender Error: 601: Error getting user information

[Mik Luciuk]

I am trying to take Winbatch code written ten plus years ago, currently running on Windows 7 (compiled), and finally trying to move to Windows 10, with the most current Winbatch +Compiler.

I'm encountering the above error but not having much luck in finding an explanation of the error so that I might understand where to start looking/fixing what the error might be. What I see in the message box is not providing information specific as to why the error is happening. I've done a fair amount of searching around but found nothing

I'm just now getting back into WIL after a long hiatus and might need a kick in the butt to "resurrect" some of the gray matter.

This is the code in my UDF

; Load Appropriate Extender
AddExtender('wwwnt34i.dll',0,'wwwnt64i.dll')
t_daserver  =  wntUserInfo(0)

Any suggestions/recommendations? Please be gentle, as I once again feel like a "newbie" :D

Thanks!

[td]

You need to do a little problem-solving.  You can start by navigating to <system drive>:\Users\<name of user running script>\AppData\Roaming\WinBatch\Settings folder and reading the contents of the wwwbatch.ini file.  Look for a section with the name of the extender either "wwwnt34i" or "wwwnt64i".  You may need to scroll down a bit as the file can be quite large and contain a lot of empty lines.  Under the section name, you should find a line with an error code and the name of a system function used by the extender function.  Report that information here along with the type of account the script is running under, the UAC settings of the script, and the UAC status of the system the script is executing on.

[Mik Luciuk]

In answer to your request, I admit that this is really my first exposure to UAC and Manifests.

To the limits of my current knowledge, here is the requested info...

Info from wwwbatch.ini file
[WWWNT34I]
LastError=1312 (NetWkstaUserGetInfo)
[Error Reporting]
3052=param1

the type of account the script is running under - Administrator

the UAC settings of the script - 2 - Process is running elevated (according to UacElevationLevel)

the UAC status of the system the script is executing on - not sure how to determine this???

[td]

System error 1312 is not one of the documented possible return values for the Win32 API function but that in and of itself is not all that unusual.  MSFT is notorious for not documenting all of the possible return values for Win32 functions.

The text for this error is documented as "A specified logon session does not exist. It may already have been terminated."  This suggests that something is amiss with the session context you are calling the extender function from.  What exactly is amiss is difficult to say.  Are you by chance calling the extender function in a logon, logoff, or a detached session script? For example, a remote desktop session not attached to a remote computer?

[td]

Another possible cause of error 1312 is running the script under the context of the SYSTEM account.  For example, Task Scheduler tasks are often executed under the SYSTEM account.

[Mik Luciuk]

I do not understand, and I'm trying to catch up, but I cannot tell you if I am "running the script under the context of the SYSTEM account"??

What I have done is to try to pair back on the what I'm doing and created the following .wbt (copy and paste out of the documentation);

; Load Appropriate Extender
AddExtender('wwwnt34i.dll',0,'wwwnt64i.dll')

daserver = wntUserInfo(3)
Message("Logon server", daserver)
Exit

When I fire up WinBatch Studio, Open the above script and step through it, I get the 601 error.

I don't think that I am calling the extender function in a logon, logoff, or a detached session script. I think that I am running  under the context of
Michael Luciuk
AzureAD\MichaelLuciuk
???

[td]

The domain name "AzureAD" suggests that you are joined to a "Cloud" based Active Directory network.  That could explain why the older Windows Network API's can't pull the user logon session information.  The function does work with traditional Active Directory based networks in our testing and returns the name of the Domain Controller hosting Active Directory.  There is some remote possibility that you have encountered the problem because you are running an elevated admin script instead of a restricted admin. It seems strange but this can happen sometimes when dealing with networks.   Of course, the way to test this is simply run the script and a restricted admin by remaining the script's extension from ".wbt" to ".wbt_if".

Another thing you might consider is if you are on an AD network is switching to using the Active Directory extender or Active Directory COM Automation objects to obtain the name of the authenticating machine.   

For example,

Code (winbatch) Select Expand

;; Untested
adSys = ObjectOpen("ADSystemInfo")
Message( 'Domain Control DN', adSys.PDCRoleOwner)
exit