locked
Session manager subsystem creates 2 additional subsystems at booting RRS feed

  • Question

  • I am using Process Monitor (microsoft product - sysinternals). I chose the boot logging option to monitor the activity on the pc since booting. The logging begins with the start of Session Manager Subsystem process  (smss.exe). What I noticed is that this process, starts 2 additional smss.exe for a short period of time. Is that normal? And if so, what is the reason for those 2 extra smss.exe

    (in case is relevant, the value for HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems\Required ="Debug Windows" )

    A 2nd really strange thing is that at some point after those 2 smss.exe exited the services.exe process with PID=608, created a new process to which it was assigned PID=496. That was the only case in the logs where a newly created process got a PID with a value lower than the current (496 was the PID of the 3rd smss.exe which had exited). Is that normal?

    Tuesday, March 15, 2016 12:10 PM

Answers

  • I don't know the internals of smss.exe (the Windows equivalent of /sbin/init on UNIX), it has many small but important things to do.  So I cannot say what those short lived extra processes do (they are probably not actual subsystems, just some tasks that Microsoft decided to run in their own process address spaces, but weren't big or independent enough to get their own exe file).

    But on all NT-based versions of Windows, PID and TID (thread id) values are really handles in a hidden handle table (that is why they are multiples of 4 just like other handles).  And as with other handles, the kernel usually allocates the lowest unused handle number whenever a new handle (in this case PID/TID) is requested.

    So when that 3rd smss.exe process exited, the PID and TID(s) it used were released (closed) and became the lowest unused numbers, so the next process or thread started got the same id as the PID of that smss.exe process.

    Because so many things start, and so few things exit during that early boot stage, most processes and threads get ids that keep getting larger, though this is technically all by chance, since there are other processes and threads that run briefly then exit during boot (the most obvious is of cause autochk.exe).  It is even possible (within documented APIs) for drivers to create and end their own threads at any time, even during boot.

    • Marked as answer by usrJohn Thursday, April 13, 2017 1:16 PM
    Friday, April 1, 2016 12:14 AM