Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.
The "wtsQuerySessionInfo" function appears to be the WinBatch equivalent of the similarly named Win32 API function "WTSQuerySessionInformation". If that specific Win32 API function is indeed the function being called (as I suspect), then the additional Win32 API function "WTSFreeMemory" also needs to be called to free the memory allocated by the "WTSQuerySessionInformation" Win32 API function once the data is extracted. This is the likely source of the memory leak within this WinBatch function.
Sample code demonstrating this condition follows and is easiest viewed using Performance Monitor and monitoring this process (a compiled .EXE for me) for "Page File Bytes". I was told to request assistance on this BBS as the author of the Terminal Services extender would see my message fastest here. To that end, just so he/she knows what's up, I'm using the latest version of WinBatch (2004D) and the latest version of the Terminal Services extender (38008).
#definesubroutine GetConsoleUserName() ConsoleUserName = "" if !wtsIsTSEnabled(1) then return ActiveConsoleSessionID = wtsGetActiveConsoleSessId() if ActiveConsoleSessionID < 0 then return PreviousErrorMode = ErrorMode(@OFF) LastError() SessionInfo = wtsQuerySessionInfo("",ActiveConsoleSessionID) ErrorMode(PreviousErrorMode) if LastError() then return ConsoleUserName = StrCat(StrTrim(StrUpper(SessionInfo[13])),"\",StrTrim(StrUpper(SessionInfo[14]))) if ConsoleUserName == "\" then ConsoleUserName = "" #endsubroutine AddExtender("WWWTS34I.DLL") while @TRUE GetConsoleUserName() BoxOpen("TEST.EXE","ConsoleUserName: %ConsoleUserName%") TimeDelay(1) endwhile
Please confirm what version of Windows you are running the script on. That will help me to prioritize the order of the tests on different versions of windows that the WTS extender runs on. Right now, that includes WinNT v4.0 TSE, Win2K Server/Adv.Server w/TS installed in remote admin or application server mode, WinXP w/FUS enabled and Win2K3 [intrinsically enabled].
Note: Current rumors have it that there is a fundamental memory handling issue that required the 34I version of the extender to be somewhat re-written to become a 44I version. This may extend the time it takes to fix the problem significantly.
BTW, I also found another memory leak. If you repeatedly call the "wtsIsTSEnabled" Terminal Services extender function, it, too, leaks considerable "regular" (private) memory when monitored with Performance Monitor, not page file memory like the other headache I gave you.
I'm no longer in any kind of rush on this. I've programmed around it for now using DLL calls to the terminal services API directly. Just FYI. I'll periodically check for a new TS extender, though, but no hurry.
I just looked in on wtsIsTSEnabled(), and it doesn't allocate any memory at all. All it does is return the value of existing global variables that get their values assigned when the extender is initializing itself. I would find it very difficult to believe that wtsIsTSEnabled() could cause any sort of memory leak at all since every variable value that it uses is either static global or is located on the stack.
Have you run it in a tight loop
while(@TRUE) result = wtsIsTSEnabled(0) if (IsKeyDown(@SHIFT+@CTRL)) then break endwhileto test for certain that a memory leak is occurring while the loop is being executed?
I'll run that test myself, too, but looking at the code I just don't see where a leak could happen - the code is too straight forward and simple to be leaking.
The update to the 44I interface specs eliminated *one* memory leak issue involving arrays with string elements being allocated in an extender & returned to a script. However, once that problem was resolved further testing showed that there was still some sort of memory leak occurring.
Further testing has shown that WTSQuerySessionInformation(), which is the underlying Win32 API function that gets session information, is actually leaking memory when certain session information items are being requested for session #0 [the console session]. The exact same function call asking for the exact same information from any other session # does not result in the memory leak, and the Win32 Platform SDK docs do not specifically call out any known issues with requesting these information items for the console session.
So far, these testing results are all on Win2K3. Now I need to go back and test on Win2K Server, WinXP Pro and WinNT v4.0 TSE to see if the problem is consistent across all versions of Windows that support terminal services or if it is only occurs on specific versions of Windows.
Article ID: W16363
File Created: 2005:02:18:12:20:04
Last Updated: 2005:02:18:12:20:04