I'm using the following API call to determine the name of the remote client in a Terminal Server session:
ret = WTSQuerySessionInformation(WTS_CURRENT_SERVER_HANDLE, WTS_CURRENT_SESSION,
WTS_INFO_CLASS.WTSClientName, buffer, bufferLen)
Usually, when the application is not running in a terminal server session, the call succeeds (ret != 0) and buffer
just returns a null pointer. So I figured that this was the expected behavior.
On one customer's machine, however, the function started to fail (ret == 0) and GetLastError
returns 5: Access Denied. (As usual, the customer claims that his system configuration did not change in any way.)
So, my questions are the following:
- What is the expected behavior when querying the WTSClientName on a non-terminal-services machine (such as, e.g., a "regular" Windows 7 PC)?
- What could be the reason that 开发者_如何学运维this error code is returned? Note that, on our test machines, the function call always behaves as expected (success and empty buffer), even if the user does not have administrative rights.
I don't know if this is relevant, but we are able to reproduce this problem (error 5) by calling the function from inside a web application. This, however, is not the case in this case (it's a regular Windows application).
I agree with you and also suppose that some from system configuration at the client are changed. To find out which one from the changes in file system or in registry are important for WTSQuerySessionInformation
you can try to use Process Monitor.
You can also ask your customer to download the tool, start the Process Monitor and then start your test program used WTSQuerySessionInformation
, save the log and post it to you. I suppose, that you will see some "access denied" errors in the log. I hope it will help you to find the problem in the configuration of the client's computer.
I don't know the expected behavior but I encountered error code 5, access denied, when calling WTSEnumerateSessions on Win7. Set DWORD
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\AllowRemoteRPC
to 1
and issue was immediately fixed.
This is happening when you call it from web application becasue the web server is running under the (session 0) of windows.
read more about session 0
精彩评论