[Upbeat music] PAVEL YOSIFOVICH: Process
Explorer is probably the most well-known tool
in the Sysinternals suite. Hi. My name is Pavel,
and I want to do a quick deep dive into Process
Explorer, see what it can do, and most importantly, how
to understand and what that, the information it
provides actually means. So, I am a developer, trainer, an author, and apparently a speaker, as well. And in fact, I've been part
of the Sysinternals team for the last nine months or so. So, if you see any new bugs
appearing in recent tools, it's probably on me. And I've been writing
a few books recently. You can find all that information online if you're interested. So, normally people
think of Process Explorer as a Super Task Manager,
because Task Manager also shows process information,
but Process Explorer shows much more information
in much greater detail than Task Manager ever could. In this screenshot, you see
the current Process Explorer on the left and some
enhancement I'll show you today on the right. So, what is Process Explorer? Its main feature is to
show dynamic information about the running system. This is mostly about processes. I mean, it is called Process
Explorer for a reason. So, it shows information about processes and whatever is contained
within these processes, such as threads, modules, handles, TCP connections, lots of other stuff. It also shows information
about kernel objects, while we view handles in the
particular process of interest. And I'll show you that, as well. It has some global
information about the system, such as CPU usage, memory,
I/O, networking, and so on. Some of the information is textual--in fact, most of it is textual--but there are some graphs that
allow you to see some things as they pass through time,
as they change through time, such as CPU utilization,
memory utilization, and so on, on a systemwide basis
or on a process basis. There's also a set of operations
you can do on processes. Well, first you can queue processes, but then there are other stuff
you can do with processes, such as suspend them and
view other information about threads and also
perhaps suspend them, as well. You can also close handles, which might come in
handy from time to time. One thing that Process
Explorer also does very well is that it allows us to
search for interesting objects across the system. So, this could be files; it
could be other named objects, such as mutexes, semaphores, and other types of
objects Windows supports. That's kind of the basic overview, but really what we want to do is look at Process Explorer itself. So, let's go to Process Explorer. Here is Process Explorer. When you open Process
Explorer for the first time, it looks something like this. You have a tree-like view of processes. And then, for each process,
you get these various columns. So, these are just some of the
columns that are available. If you want more, you can right-click, go to "Select Columns," and
then you get a very big list of columns divided into various categories to make it a bit easier to
find what you're looking for. First, consider this
tree-like data structure. What does that really mean? If I go ahead and double-click
one of these processes, we can see in the "Image" tab. It talks about the parent of the process. So, the parent of this
particular process is SVC host, with the process ID 1444, which happens to be exactly this one as it's shown here in
the tree: here's 1444. Of course, we can move columns around if we want them to be
in a different location. So, it talks about and shows
the parent of that process. Now, for some processes, it seems that they're
completely left justified. It seems like they don't have a parent. So, let's take a quick
example, such as winlogon here. If I go ahead and double-click "winlogon," apparently winlogon doesn't
have a parent process. It's a nonexistent process,
which has the ID 1216. So in fact, it was the
process ID of that process, but no other information is
available for that process because that process is now gone. And the parent process ID is
stored in the child process ID. Now, it's important to
understand in Windows that there is no parent-child relationship in terms of any kind of dependency, which means that if
process A creates process B and process A dies, process
B is completely unaffected. So, we have this process
which doesn't have a parent. What about this ID, however? Can a new process be created
that has the same ID? The answer is yes:
Process IDs are not unique throughout the lifetime of the system. They're only unique as long
as the process is alive. However, Process Explorer is not confused if it has another process called 1216 that has since been created. Process Explorer also compares the start time of that process. If the start time is
after our current process, then surely it can't be the
parent process for that process. And so, a process doesn't get confused and will still show a nonexisting process for that particular case. So, the question, "Who created who?" is sometimes interesting to understand how things get created. And that's what the
tree-like structure shows us. If you want to sort in a
normal way, you can see, to go ahead and sort
from A to Z or Z to A. The other thing that is fairly obvious in Process Explorer are these colors. So, these colors are not for
making Process Explorer pretty, although that might be a
good reason for having them, but for each color, there
is some significant aspect that is part of the process in question. So, let's see a few examples. One of them is these yellowish process. So yellowish processes are for .NET, which means that that particular process is hosting the CLR, the .NET runtime. And when you double-click
or look at the properties for that process, you'll find
that there are two tabs here. One of them is called ".NET assemblies," which shows all the .NET assemblies loaded into the application
domains of this process. And there is a ".NET performance" tab here that shows some performance counters that you can find in
usually using other tools, such as Performance Monitor. And this is the .NET CLR memory category, but there are other categories here which are also related to .NET. So, for other types of processes
that don't host the CLR, you will not see these
tabs in the properties. These are contextual tabs; they only exist for .NET processes. Let's take another color as an example. We have this pinkish color. So, this pinkish color is for services. And just like with .NET,
there's a special tab in that particular case called "Services." So, you see that in
this particular example, I've double-clicked an executable, which is hosting a single
service right here. And in fact, it is
implemented as an executable, which normal processes have
to be implemented in this way. However, if you're familiar with Windows, you probably are very familiar with this thing called "SVC host." And this SVC host thing is
a generic host for services that Windows uses for most of its services coming out of the box. If I double-click any one of those, we'll see the "Services" tab
existing in that properties, but then, you'll notice that
the actual implementation is for services in a DLL, which makes sense because we
have a generic executable, a generic process to host the services, so the particular detail of the specific service has to be coming
from somewhere else, which is that DLL. And in today's systems,
you'll find that most services are actually hosted in their own process. You can see there are many, many SVC host instances here flying around. There is one perhaps
that is a bit different and it's hosting multiple services. One of them is very, very important: That would be the DCOM launch service, which is critical to Windows, in fact, and Windows can't really
function without it. It has some very important
responsibilities. So, the ability to host multiple services in the single process,
this is the thing that is using these DLLs for. So, the ability to have
services implemented as DLLs allows us to load multiple
services into the same process. And previously, before
Windows 10 version 1703, there was some form of segregation, where you had multiple services in a single process to conserve processes, to conserve system resources. However, starting with
version 1703 of Windows 10, if the system has at least 3.5 GB of RAM, for standard systems that's
probably not an issue, but could be an issue for
IoT devices or Windows Phone and such small devices, then most services get their own process. And this is for robustness and stability. So if one service crashes,
it brings down its process, and the only service that
is affected is that process. On the other hand, if you
have multiple services in the same process, one
service causes some exception, then the entire process shuts down, causing all the other services, which are not to blame, to crash, as well. So, pink processes are about services that are hosted in that
particular executable, that particular process
to be more precise. Then, we have these cyan colors. So, this cyan color is mostly
used for UWP processes. So, for example, I have a
calculator here running. And if you go ahead and
look out for Calculator, we see that it has this cyan color. So, these are applications
that are usually using the Windows, they're
using the Windows runtime, and they have some extra
management on top of them. For example, if I go ahead
and minimize Calculator now, you'll notice that the
process becomes suspended and changes color to the suspended color [if I enabled that color], which means that all the
threads in the process have now been suspended, and nothing can happen in Calculator. Once I restore Calculator,
its process goes back to life, and it can continue doing
it's calculator thing. And so, most cyan processes you'll find are these kinds of processes,
but it's not precise. So, for example, if we go
ahead and look at Explorer, you'll find that Explorer
also has this cyan color. Does that mean that Windows
Explorer can be minimized, causing it to be suspended? The answer is no. And the cyan color really is about hosting the Windows runtime using
Windows runtime APIs. Behind the scenes, there is a function that is a massive
process, which is the one that's actually being
used by Process Explorer to determine whether to color
a process with the cyan color. And so, Explorer is definitely
not a UWP application, but it is using Windows runtime APIs, and that's why we get that color. You also find many processes
of type runtime broker, which are helpers; UWP
processes that allow them to do certain operations, which
they cannot do on their own. And that's because UWP
processes run inside something called an "application
container," or "app container." You can see that in the
"Integrity" column here, and "container" means, among other things, very low power in the sense
that you can't access, you can't access resources or objects that have a medium
integrity level or higher in any invasive way. That container really
means low integrity level. So, integrity level is another
very interesting aspect of Windows security, but
unfortunately we don't really have time to discuss that. So, we have these colors,
and let me talk about maybe one or two other colors. So we have this particular color, this is a color called fuchsia. This is the default hue
for protected processes. So, protected processes
can't be accessed invasively from user mode regardless
of the user's powers. So, even if the user is an administrator or has any crazy privileges,
it doesn't matter. You can only get very shallow information about a protected process. Whether that's protected
with the classic protection from Vista or the protected process light, which is the enhanced protection or more, I would say, flexible protection model from Windows 8.1 and later,
you can figure that out using that "Protection" column. So if I want, I can even
sort here by protection. You can see the various protection values that you have here. And these are based on the signer and the level of the signer. So, some signers are more
powerful than others, and there's these two modules,
the classic protected model and the protected light model. And so, this is the fuchsia column. By default, you will not see that color because it is not enabled by default. So you can go to "Options
> Configure colors," and then enable that color, if you wish. So I've enabled most of
the colors except for jobs. We can do that, as well. And in that case we'll
find that many processes get colored with that brownish color. These are processes
that are part of a job. And just like with other cases, when I double-click one of these, we get another contextual tab
here, which is the "Job" tab. And the "Job" tab shows all the processes that are part of that job. In this particular case I've selected one of the instances of WmicroVSE, which is the WMI worker
process or worker executable, which we have multiple instances running. And we can see that there are
some limitations on that job. So the purpose of a job in general is to manage a set of processes as a unit, providing some form of limitations or limits to these processes. So you can see here
some limits, so that WMI service request and operations
that are going to happen because of that request will not consume too much system resources. So, for instance, the job can not consume more than 1 GB of memory. Number of processes cannot go beyond 32. So, Process Explorer shows
you the limits that a job has. So again, this tab is
contextual and will not appear for processes that are not part of a job. So, these are some of the colors you can find in Process Explorer. And as we've seen, you can
configure those to see them or not see them based on your preferences. And so, other than
that, the important part that we see in Process Explorer
is that it has a lower pane. So, you can show that lower pane by clicking some toolbar button and using the Ctrl-L shortcut. And once you do that, what you get is a pane here at the bottom
that now contains three tabs: "Handles," "Modules," and "Threads." This is a new feature in Process Explorer. Previously, you had only
"Modules" or "Handles," and you could switch between them. But now we have some tabs here, which you can switch between and show threads also, and not
just modules or handles. So, any process you select here, it doesn't really matter
which process that is, you get the view changing
based on your selection. And of course you can sort
any one of these columns in terms of threads here, and
even perform some operations, such as looking at the
call stack, the module, maybe even terminate the process, sorry, the thread, and suspend the thread, as well, if this is what you want. And of course, we can
switch to the models view to see all the models
that are currently loaded into the process address space, seeing the name, description, path, and the base address and image base. So, the base address is where
the DLL is actually loaded. Image base is where the DLL
would have liked to be loaded. And if these things are not the same, it means that the DLL has gone
through a relocation process. And this is also marked in this
yellowish color right here. So, you can see here that the
numbers here are different, which means that this particular DLL had to be relocated because
it's preferred address was already taken. So, we can see here a list
of properties for DLLs. And of course, this is just
a partial list of columns. You can right-click, you
get to the "DLL" column, and you can select other
columns you would like to see because by default, you actually don't see some of the columns I'm showing here. And then, we have the "Handles" tab. So, the "Handles" tab is about
showing us all the handles that are part of the handle
table of the process. We know that every process
has its own handle table. And these handles point
to various kernel objects. In fact, most of the
functionality in Windows is provided through kernel objects. So, if you want to do stuff, for example, you want to open the file,
you have to obtain a handle to a file object that
represents the connection to the file you would like to talk to. And without the handle, you
can't really talk to the file. And so, these handles are just numbers that are indexed into some tables, which are in kernel space. But you can see the numbers right here. And you need to remember
that every handle table is private to the process. So, if I have a handle
here to some registry key with the value of 78X, I can't just pass along that number
to a different process. That doesn't make any sense
because the other process has its own handle table where 78 points to a completely different
object or maybe to nothing. And so, it's important to realize handles are private to a process. So again, when you just
start up Process Explorer for the first time, you just
see the type and name columns, but you can right-click as always, and show more columns
for looking at handles. So you can see the handle value, and the first handle which
is valid has the value of 4. Zero is never a valid handle value. You can see the type of object, and Windows has many types of objects, some of which we understand very well because we can use them and
we see them all the time, such as processes and
threads and registry keys and files and so on. Some of them, perhaps not so much because they are more internal and some of them in fact
are completely undocumented. Here we can see the name of the object, and this is kind of a tricky column. It's not really the name
of the object in all cases, but it is some form of name
that makes it easy for us to understand some more
details about the object that is pointed to by that handle. I'll say a few more things
about that in just a moment. Then, you have the access mask here. The access mask is a
set of bits indicating what is the power of that handle? So, I might have multiple
handles to the same object. It doesn't mean that all
these handles are the same. Each handle has its own power. And so that power is
represented by the access mask. For instance, this registry key
has the access mask to 0019. And in order to understand
what that really means, we have to go to the
Windows SDK documentation to figure out what each
of these bits mean. Or, we can just look at
the decoded access column, which tries to interpret that
value in a human readable way. So, essentially we can
see here that this handle can do read operations
from that registry key, which means that if it
tries to do something like a write operation for that key, that would fail with access denied. So, not all handles are born the same. Same goes for every other
handle you see here. Then we have the object address. The object address is
where the real object is included in the space. You can see here that the
address is a very big number, which is what we expect
on a 64-bit system, because the kernel space starts
at the upper 128 terabytes of address space. So, this is somewhere
inside that address space. What can you do with that address? Well, onto itself, nothing. From user mode, that information
is practically useless, but if you're doing some kernel debugging or have a kernel debugger
available to you, you can actually use that
address to gain more information about the object by looking at it through the kernel debugger. So for instance, if I go
ahead and double click one of these handles, what we see here are properties for the object. So notice the properties
are for the object, not for the handle. The properties of the
handle itself is just represented here by this line. Which means that if I
double click two handles that point to the same object, I'll see the exact same information. Because this is about the
object, not about the handle. And so you can see the name of the object, the type, some description. Here's the address, again, where the object is in kernel space. We can see here a number of handles that are open to this
object, currently just one. Then we have references,
which is kind of weird because supposed to give us the total reference count of an object. Kernel objects are managed
with the reference count. And only when the reference
count goes to zero, only then the object is destroyed. However, if you look at
Windows 8.1 and later, the reference count seems like something that doesn't really make much sense. I mean, would there
really be 65,000-something kernel clients holding
pointers to the object or something like that? It is unlikely. So in fact, this number
combines a usage for the handle, so to actually see what it really means, Process Explorer in this case fall short; there's no way to get that information from user mode very easily. We can go to a kernel
debugger just for fun and just use the object
command with that address. And then we get the information about the fact this is a registry key. And you see the same pointer count or something a bit different
because it is based on usage. You can click that, and then
you get the true ref command, which will show you the
real reference count for these objects, which takes a few, a couple of seconds to
figure this thing out. But eventually you would
get the actual results. So, this is something we can't
get from Process Explorer because it doesn't have the full view of what is going on in the kernel. However, in the meantime,
one thing I did want to show in terms of
modules before I forget, if I go to something like CSR recess which is a protected process,
notice we see the list of modules and DLLs inside this process. If you've used previous
versions of Process Explorer, you wouldn't see that information. But now we do, and that's because we use the Process Explorer driver,
assuming you're running Process Explorer with admin privileges, to open a powerful handle to the process and circumvent the limitation
you get from user mode not being able to access
invasively, protected processes. But now we can, because we
leverage the power of the kernel. So now all protective processes
do have a list of modules and the list is not
empty, as you might find in previous versions of Process Explorer. So, back to handles, here's
the actual pointer count. That would be one. So, the reference count is one, which means this is the only handle and pointer to the object. So, back to handles
here, one of the perhaps trickiest parts here is
understanding the role of name. In fact, when you think of
the list that you see here, is this the entire list
of handles in the process? So, not really. This only shows named object as far as Process Explorer is concerned. To see the true list of all
the handles in the process, we have to go to the
View menu and select here Show Unnamed Handles and Mappings. Once we do that, we see that
the list is greatly extended. Now we have many more
handles than we previously saw in the process. And that is truly the full
handle table for the process. You notice that handle number
four does really exist. And number eight exists as well. These are just for objects
that don't have names, which are just normal objects
just like anyone else, and they just don't have
names, which is fine. The name is definitely not mandatory, and some object types, in
fact, can't have names anyway. So, this is fine. Previously we've seen
34 is the first handle, but in fact it is not the first handle. So, back to named objects only. I want to focus on names a little bit. So, these names are not really
that trivial to understand. Some objects are truly named. They do have names, for
example, sections have names, events have names, semaphores
and mutexes have names. And these are true names, which
means we can open the object by name, using an appropriate API. However, some objects here
that seem to have a name don't really have a name. So, let's look at some examples. One of them is process. So, processes don't really
have names, processes have IDs. However, Process Explorer shows us a name for the process because it is just useful to see that information, but it is not a true name. This is the process ID, of course. But it shows us as a named object. Same goes for threads. Threads also don't really
have names, they have IDs. So, we can see here that
this particular handle points to a thread inside Explorer itself, and that will be the thread ID, which of course is something
that might be useful information for us, but
it is not a named object. So, you might be familiar with the feature introduced in Windows 10
where you can actually give a description to a thread using the set thread description API. And so, you can associate
a string with the thread, but it is not a thread name. It doesn't have to be
unique and there's no way to look up a thread based
on that description. In fact, it's mostly used
for debugging purposes. We just really can show the
description of a thread, for example, that could help you identify interesting threads in your application. So, these are not-named objects. Another type of object
which is not named are keys. Registry keys don't really have names. This might seem very odd. What do you mean, you don't have a name? Here's a name, but no,
this is just the path pointing to register key; the object itself doesn't
really have a name. And the most confusing
aspect is definitely Files. So, file objects really don't have names, which seems really, really old. I mean, what do you mean
they don't have names? Isn't that a name for
a file or a directory? So yes, this is a path, but it is not the name of the file object. This is not really about files. File objects are a way to contact or to communicate with devices. Where files in the file system
are just one particular case. And to prove that there is another tool I would like to briefly
show you, which is winOBJ. winOBJ is another Sysinternals tool that shows us all the named
objects in the system, all the truly named objects in the system. And they are managing in this
kind of hierarchical manner. Let me run this with admin privileges so that we can see everything. And so, you can see various
types of objects here, such as events, and
semaphores, and in fact, under sessions one in basement objects, you'll find all the named objects created by processes in session one. So, I dare you to find here a file. You won't find the file here. You won't find a registry key. You can search, but you won't
find anything like that. This is kind of a proof that file objects don't really have names. You can't open a file object by name. You can open a file, which
is a different thing, and you'll get a new
file object representing your connection to that file or device. But this is not about names at all. So, file objects don't really have names, but Process Explorer
shows file objects here as though they have names
because it is, of course, a very convenient and
very nice thing to see that I can know which handle
points to which actual file. So, this is definitely convenient, but it's not really a name for the object. Another feature of Process
Explorer is the ability to find. You can use Control + Shift + F to open this dialogue
for performing search. And it says handle or DLL substring, but really it means any
kind of named objects, as names as Process Explorer sees them. So, if I write something,
part of a name or whatever, that maybe we might be
able to find something. So, I can do something maybe, Explorer. So, Explorer could be
related to DLL names, could be rated to mutexes
that have the name, the string Explorer somewhere there. So, you can see everything
that has these Explorer thing searched throughout the system. And then of course we can,
while we can cancel the search, if we have too much items, too many items, anyway, in any case we can
click any one of these entries and we jump to exact to
the process and the handle that this thing represents. So, the search is really
about named objects, including naming as far as
Process Explorer is concerned, which means find names as well. So, one very classic
case where this is useful is when you're trying to delete some file and that file fails to delete because someone is holding that file. And so, Process Explorer can allow you with that search option to
quickly locate the processes or process that has an
open handle to the file, which is why you can't delete the file. And then you can just close
the handle if you wish or terminate the process,
and then you'll be able to close, to delete that file. And so if you right click here, you can actually close the handle. Normally I don't recommend it, but if you know what you're
doing, you can do that. You can close the handle
behind the process back. So, this is, again, something
that you can't do very easily. So, the close handle API that some of you are
probably familiar with can only close the handle
in the current process. But in fact, there is a way to close handle in another process
using the duplicate handle API with the flag, duplicate closed source. And that's kind of the way
Process Explorer does it, in order to actually close the handle in a different process. Usually this is very dangerous in a sense, because the other process
would get its handle kind of going away
without even noticing it. So, this is Process Explorer, some of the aspects of Process Explorer. Of course, there are many other
things I could talk about, but we only have 30 minutes and
my 30 minutes are almost up. Thank you very much. I hope you enjoy Process Explorer. I hope you enjoy the new features and hopefully we'll continue
to evolve Process Explorer even further and other
tools, as well, of course. Oh, and one last thing. If you're like me and
you like something darker than these bright colors,
you can use Options, Theme, and switch Process
Explorer to a dark theme, which is of course new
feature in Process Explorer that I hope you like.
