Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Defrag Tools: #32 - Desktops

Download

Right click “Save as…”

In this episode of Defrag Tools, Andrew Richards, Chad Beeder and Larry Larsen walk you through Sysinternals Desktops. Desktops allows you to organize your applications on up to four virtual desktops. We go under the covers and show how Desktops fits in to the Session, Window Station and Desktop object/security model.

** I didn't do a great job explaining Sessions/Window Stations/Desktops -- If you want to know about those concepts in detail, I suggest you watch Sysinternals Primer: Gems instead.

Resources:
Sysinternals Desktops
Sysinternals WinObj
Sysinternals LogonSessions
Aaron Margosis' TSSessions
Sysinternals Administrator's Reference - [Amazon]
Sysinternals Primer: Gems [TechEd EMEA 2012 @13:45]
Malware Hunting with the Sysinternals Tools [TechEd USA 2012 @ 44:30]

Timeline:
[01:05] - Sysinternals Desktops
[04:50] - Sessions, Window Stations and Desktops
[05:13] - Sysinternals WinObj
[05:43] - Sessions
[06:40] - Window Stations
[09:00] - Enumeration (Standard User)
[10:11] - Desktops
[11:38] - Local Security Authority (LSA) - Sessions via Logons *
[12:16] - Enumeration (Elevated User)
[15:20] - psexec -sid cmd.exe
[16:38] - Enumeration (NT Authority\SYSTEM)
[17:15] - Sessions via Logons (NT Authority\SYSTEM)
[18:26] - Media Center Extender example

* You can enumerate sessions directly via the Remote Desktop Services API.

Exercises:

Use Sysinternals LogonSessions to view the logon sessions.
Use Aaron Margosis' TSSessions to view the Sessions/Window Stations/Desktops (and much more).

Session: 0
  WinStation: WinSta0
    Desktop: Default
    Desktop: Disconnect
    Desktop: Winlogon
  WinStation: Service-0x0-3e4$
  WinStation: Service-0x0-3e5$
  WinStation: Service-0x0-3e7$
  WinStation: msswindowstation
     Desktop: mssrestricteddesk
Session: 1
  WinStation: WinSta0
    Desktop: Default
    Desktop: Disconnect
    Desktop: Winlogon
...

Tags:

Follow the Discussion

  • d_blkdcrearer d_blk

    Cool show...

    Bring on Xperf - I would love to see a series on the utilization of Xperf to diagnose I/O issues.

    Like determining what is acceptable latency for i/o completion.... thorough walk through. 

    You'll are providing an awesome service. 

  • Aaron MargosisAaron Margosis

    I really hate to say it, but this particular episode contains an awful lot of incorrect information. Per your request, Andrew, I'm posting comments and corrections here. Thanks for posting the link to my Sysinternals Primer: Gems talk which covers many of the same topics; Windows Sysinternals Administrator's Reference (which I co-authored with Mark Russinovich) also covers a lot of these in Chapter 2 and in the LogonSessions write-up.

    6:08 - The concept of TS sessions, and sessions 0, 1, 2, etc., was not invented in Windows Vista – it was first created in NT 4 Terminal Server Edition. It’s present in Windows 2000 Server, and was introduced to client in Windows XP. It’s the basis for Fast User Switching in XP (when not joined to a domain).

    6:25 – “if you remote desktopped in, you’ll see a much higher number, like in the 60,000 range.” No, you still get incrementing session numbers. You’ll see sessions above 65k, but AFAICT they are used only when establishing new TS sessions. The new TS session gets ID 1, 2, 3, etc. – or can take over an existing TS session, including what had been the console session.

    6:43 – “Window stations roughly represent the rendering ability of Windows, the ability to put windows on the screen.” Actually, this description is more accurately applied to desktops than to window stations.

    7:00 – WinSta0 isn’t “the first” window station. In sessions other than session 0 it’s usually the only, but I wouldn’t say its existence predates those of the other window stations in session 0. However, WinSta0 is the only window station that can be interactive, that can have its desktops render on a display device (whether attached monitor or RDP). Apps can create additional window stations, but anything that runs within one cannot render on a screen.

    7:10 – “It’s very rare that you’d see more than one window station in a session” – except for session 0, where there are different window stations for every account that runs a service, plus msswindowstation which is used to isolate instances of SearchFilterHost.exe.

    7:30 – “I can see my own window station, but I can’t see the window stations of session 0”. It’s true that you can’t enumerate the window stations of other sessions using the WTS APIs, but the reason you don’t see any window stations in WinObj under \Sessions\0 is because session 0’s are in \Windows\WindowStations. (Similarly, you see \Sessions\n\BaseNamedObjects for n > 0, but not in \Sessions\0\BaseNamedObjects – that’s because session 0’s BNO is global: \BaseNamedObjects.

    7:45 – “you’ve got to run in the context of the window station to enumerate the desktops” – not true – you just need a handle to the window station that grants the enumerate desktops right. Some of those are very restrictive, but others aren’t. E.g., the sole ACE in the msswindowstation DACL grants rights to Everyone, so you can enumerate its mssrestricteddesk desktop. (That said, I don’t know why WinObj doesn’t show any desktop objects. “Desktop” is listed in \ObjectTypes.)

    7:49 – “If you go down to the bottom one [\WIndows\WindowStations], … there is more window stations registered on the box.” This isn’t a list of all window stations on the box, it’s the window stations of session 0. The Windows object manager predates TS sessions, and not everything that’s now session-specific (like the window stations of session 0) moved from its original location to a subdirectory of the relatively newer \Sessions directory. Also, there are WinSta0 window stations in every session (at least those that I’ve enumerated), including session 0. The WinSta0 in that directory belongs to session 0.

    8:17 – “Local account” – I know you meant “Local Service”.

    8:45 – repeating incorrect statement that you can’t enumerate desktops of another window station.

    9:20 – EnumSWD.exe is confusing LSA sessions and TS sessions. I consider them orthogonal. Even though LSA sessions are “associated” with a TS session, there is no restriction (that I’m aware of) that prevents a token associated with an LSA session associated with TS session 0 from being used by a process running in a different TS session.

    11:20 – different sets of APIs to show what’s going on – you’ve got the window station APIs and the LSA APIs. You’re missing the WTS APIs to enumerate TS sessions! See my TSSessions link – it comes with source.

    11:30 – hard to work out what other sessions are on the box, “because it’s a security boundary” – no, just use the WTS APIs.

    13:10 – “there’s one more that you don’t see because it’s made on demand, called the secure desktop.” “Secure desktop” is just another name for the Winlogon desktop. (The screen-saver desktop is made on demand, though, and it runs password protected screen savers.) UAC does not create or use desktops that didn’t already exist. What’s really special about Winlogon is that it grants access only to System, so only processes running as System can run there, enumerate windows, etc. (It grants a little tiny bit of access to admins too, but not enough to let you do anything without first changing the permissions.)

    14:36 – “what [Mark] did”, describing using Desktops to get around Sysinternals-killing malware – that actually came from a Sysinternals user, not from Mark, but we used it in the Case of the Unexplained portion of the Windows Sysinternals Administrator’s Reference.

    14:57 – “the ability to kill processes is at the session level”. I don’t know what you mean here. If you have PROCESS_TERMINATE or equivalent for a given process, you can kill any process. If you’re admin you can kill any process. The reason non-admin processes can kill admin processes on the same desktop is that all processes in a TS session tend to have an ACE with the logon SID used in the TS session granting Terminate.

    15:50 – “the interactive session” – there can be multiple simultaneous interactive sessions. With psexec -i you can specify a TS session number; If you use –i but omit the session parameter, PsExec runs the process in the current desktop session when run on the local computer, or in the current console session when run on a remote computer.

    16:25 – I wouldn’t describe TrustedInstaller as “higher” than System; the Trusted Installer service runs as System, after all; it just happens to have NT SERVICE\TrustedInstaller in its groups list, and some system resources grant full control only to that service SID.

    17:08 – are you sure that’s what the Disconnect desktop is? I thought if you were disconnected then it was up to the client program (mstsc) to render a screenshot of what it last saw, not that you’d be connected to a remote desktop continuing to render that shadow.

    17:20 – (trying to use the LSA enumeration APIs instead of the WTS APIs to determine existing TS sessions…)

    17:40 – “a logon of the computer object itself” – not exactly – that’s either the SYSTEM or NetworkService logon SID; show the SIDs as LogonSessions.exe does and you can tell them apart – the name is just what the SID-to-name translator converts to – it could also do “NT AUTHORITY\NetworkService”.

    18:00 – Window Manager\DWM-1 – “a user logged in who knows how to control desktop window management.” Not publicly documented (AFAICT) but “Window Manager” appears to be a new authority (S-1-5-90) that seems to create something akin to service accounts.

  • wilwil

    Hello, I'm using 2 laptops,
    I'm using Desktop (from msft/sysinternals, because it is the fastest to switch on the market)
    and I'm also using "Mouse without Border" from Msft

    They both really work well individually but soon as you start to use both there are few issues, here are 2 of the main one
    it will be great if either the desktop developer or the "Mouse Without Border"(MWB) developer could look into it and solve the issue.

    1) Switching screens with desktop work really well and fast but soon as MWB is started some ALT 1 -> ALT 2 -> ALT 3 can loose some signals so the screen doesn't switch
    (to reproduce switch many time quickly ALT 1 <-> ALT 2 etc.. and you will see some are lost)...this happen a lot when I'm working which is problematic.
    2) So here both Desktop+MWB are started on both computer, I move the mouse to the other screen and press ALT-4 (4th screens) and then I loose the mouse?
    3) if I'm on the keyboard computer and go to alt-3 for instance (3rd screen) and try to move the screen on the border to navigate to the other computer it doesn't work (it will work for alt-1 and alt-2)

  • Andrew Richardswindev Andrew Richards

    @wil: You are a true power user Wil!!!

    I'll tell Mark (Desktops) and the MWB dev about the issues. Since it is a rare combination, I can't promise if anything will change, but I will ask.

  • If I recall correctly somewhere around episode 4 it was mentioned there would be some xperf action in a later show.  Is that still planned?

  • Andrew Richardswindev Andrew Richards

    @Imperfect1: It is. Since a new version came out with Windows 8, Chad and I are having to do a lot of study to get up to speed. We are also trying to get some guest hosts on the topic...  They are coming, we promise.

  • mihaimihai

    Hello. I want to create an app that allows multiple users to use different keyboards and mice to control separate desktops, on separate monitors, on the same computer.

    Basically, I want to create something like Windows Multipoint Server, but very very lightweight.

    Can you please provide a few pointers?

  • Andrew Richardswindev Andrew Richards

    @mihai: You'll need to have in-depth knowledge of Windows Hooking and the I/O Kernel stack to achieve that.  Why can't you just use Multipoint Server?

  • mihaimihai

    Thank you very much for your reply.
    I want to make the app just so I can learn, and also, maybe it will be a cheap solution for homes where there is a single computer and many family members who want to access it at the same time (in this case multipoint server would be too costly). Also, the app might help reduce costs for school labs, or double, possibly tripple the number of labs in a school.

    The first thing I wanted to do was to recreate the Desktops app. Then I'll continue with reading raw input from usb ports for seconday keyboards and mice, and redirect those inputs to the appropriate desktops.

    Is the source code for the Desktops app available?

    A little guidance from you would be immensiley helpful. If it's not too much to ask, can we please continue this conversation via email?
    Thank you very very much.

  • Andrew Richardswindev Andrew Richards

    @mihai: You don't really want desktops for this, you want the ability to direct rdp sessions to local monitors. It is a massive undertaking. I do highly suggest that you suggest MultiPoint Server to any user you know.

  • mihaimihai

    Thank you very much for your answer. Directing rdp sessions to local monitors was a fantastic idea. I managed to get it working.

    I'm currently trying to create a kind of driver that captures all input from keyboard and mouse, filters by device and sends the appropriate input to each rdp client window.

    When the app will be finished I will post a link back here. Thanks again for your help.

  • PsyPsy

    I use virtual desktops extensively wile working on a notebook. There are a variety of tools out there, all of them have some flaw or feature missing, and I'm wondering why Microsoft still does not have this functionality built in the OS.

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.