Unlike the Process Explorer utility that we’ve spent a few days
covering, Process Monitor is meant to be a passive look at everything
that happens on your computer, not an active tool for killing processes
or closing handles. This is like taking a peek at a global logfile for
every single event that happens on your Windows PC.
Want to understand which registry keys your favorite application is actually storing their settings in? Want to figure out what files a service is touching and how often? Want to see when an application is connecting to the network or opening a new process? It’s Process Monitor to the rescue.
We don’t do a lot of registry hack articles anymore, but back when we first started we would use Process Monitor to figure out what registry keys were being accessed, and then go tweak those registry keys to see what would happen. If you’ve ever wondered how some geek figured out a registry hack that nobody has ever seen, it was probably through Process Monitor.
The Process Monitor utility was created by combining two different old-school utilities together, Filemon and Regmon, which were used to monitor files and registry activity as their names imply. While those utilities are still available out there, and while they might suit your particular needs, you’d be much better off with Process Monitor, because it can handle a large volume of events better due to the fact that it was designed to do so.
It’s also worth noting that Process Monitor always requires administrator mode because it loads a kernel driver under the hood to capture all of those events. On Windows Vista and later, you’ll be prompted with a UAC dialog, but for XP or 2003, you’ll need to make sure the account you use has Administrator privileges.
What it does do is capture specific types of I/O (Input / Output) operations, whether they happen through the file system, registry, or even the network. It will additionally track a few other events in a limited fashion. This list covers the events that it does capture:
When you first load up the Process Monitor interface, you’ll be presented with an enormous number of rows of data, with more data flying in quickly, and it can be overwhelming. The key is to have some idea, at least, about what you are looking at, as well as what you are looking for. This isn’t the type of tool that you spend a relaxing day browsing through, because within a very short time period, you’ll be looking at millions of rows.
The first thing you’ll want to do is filter those millions of rows down to the much smaller subset of data you want to see, and we’re going to teach you how to create filters and zero in on exactly what you want to find. But first, you should understand the interface and what data is actually available.
One of the reasons for adding additional columns to the display is so you can very quickly filter by those events without being overwhelmed with data. Here are a few of the extra columns that we use, but you might find use for some others in the list depending on the situation.
The default Event tab gives you information that is largely similar to what you saw in the list, but will add a bit more information to the party. If you are looking at a file system event, you’ll be able to see certain information like the attributes, file create time, the access that was attempted during a write operation, the number of bytes that were written, and the duration.
Switching over to the Process tab gives you lots of great information about the process that generated the event. While you’ll generally want to use Process Explorer to deal with processes, it can be very useful to have a lot of information about the specific process that generated a specific event, especially if it is something that happened very quickly and then disappeared from the process list. This way the data is captured.
The Stack tab is something that will sometimes be extremely useful, but often times will not be useful at all. The reason why you would want to look at the stack is so you can troubleshoot by examining the Module column for anything that doesn’t look quite right.
As an example, imagine that a process was constantly trying to query or access a file that doesn’t exists, but you weren’t sure why. You could look through the Stack tab and see if there were any modules that didn’t look right, and then research them. You might find an out of date component, or even malware, is causing the problem.
Or, you might find that there isn’t anything useful here for you, and that’s just fine too. There is a lot of other data to look at.
Buffer Overflows
While yes, many hackers and malware creators exploit a buffer overflow weakness to remotely or locally hack into a component and gain extra access, this error message is actually built into the Windows API and means the complete opposite.
In the example for the screenshot above, the application queried the registry for a specific value, but told the Windows API to put the result into a place in memory that was too small to fit all that data. So Windows returned back the message to let the application know that they need a bigger spot to put all the data. That’s all it was.
Note: you can also use the Search Online feature to quickly search for the name of the process, the registry path, or any other field, which can be really useful when you don’t understand what something is used for.
In the example above, you can see that the application we were monitoring was trying to look at a registry value, so we used the Jump To feature, and Process Monitor immediately opened the Registry Editor already focused to that exact key.
So now we know, the application is trying to figure out where my appdata folder is, and we know which folder that was… which helps explain what is going on.
In this case, the application was the Conduit search malware, and it was looking for my user folder by querying the regisry so that it could start messing around with files and folders inside of my Google Chrome profile.
You can very quickly filter by any column using the context menu and using the Include or Exclude features — if you Include an item, the list will only contain events that match that particular item, or any others that you specifically include, but will not contain anything else. If you Exclude an item, everything will show up except for events that match the very specific item that you excluded.
In this case we decided to Include the cltmng.exe process, and now every single thing that we see in the list is related to that process.
You can alternatively use the Edit Filter option from the menu, or access the Filters section of the menu to display the list of filters and edit them. You can choose from the drop-down dialogs and match by any of the available fields, choose whether the value you type into the box will be matched exactly, or just “starts with”, or a number of other options. Then you can choose whether to Include or Exclude events that match those criteria.
Just don’t forget to click the Add button once you’ve defined your filter and before you click OK or Apply, because otherwise your new filter won’t actually be activated. Trust us, this is a common mistake!
You can also remove or edit filters by selecting them in the list and then modifying or removing them.
What’s actually going on here is that the instance of Process Monitor is showing only the items that match the filter, but everything else is still being captured in the background, which can be a TON of data after a very short time — note the status bar in the example below that we had running for just a few minutes. If we had the Drop Filtered Events option turned on, it would have only captured just the events we wanted.
There is a big drawback to using this feature though, and that is that you can’t get back those filtered events if you realized you filtered the list by too much, and wanted to examine events from another process. You’d have to redo your entire scenario, which might be too late. So make sure to use this option with caution.
Imagine you are working on somebody’s really old and lousy computer, and you want to diagnose a particular problem, but the computer is just running way too slow to sit there and deal with it the entire time. You can simply run a Process Monitor scan on their computer, save the data over to a flash drive, and then load up Process Monitor on your blazing fast personal laptop and get to work analyzing what might have happened. You can even go to the coffee shop and analyze from there.
And of course, you could also just remotely talk somebody through running Process Monitor, doing a scan, saving the file, and then sending it to you for analysis. That way you don’t even have to show up and see them in person.
SOURCE : HOWTOGEEK.COM
Want to understand which registry keys your favorite application is actually storing their settings in? Want to figure out what files a service is touching and how often? Want to see when an application is connecting to the network or opening a new process? It’s Process Monitor to the rescue.
We don’t do a lot of registry hack articles anymore, but back when we first started we would use Process Monitor to figure out what registry keys were being accessed, and then go tweak those registry keys to see what would happen. If you’ve ever wondered how some geek figured out a registry hack that nobody has ever seen, it was probably through Process Monitor.
The Process Monitor utility was created by combining two different old-school utilities together, Filemon and Regmon, which were used to monitor files and registry activity as their names imply. While those utilities are still available out there, and while they might suit your particular needs, you’d be much better off with Process Monitor, because it can handle a large volume of events better due to the fact that it was designed to do so.
It’s also worth noting that Process Monitor always requires administrator mode because it loads a kernel driver under the hood to capture all of those events. On Windows Vista and later, you’ll be prompted with a UAC dialog, but for XP or 2003, you’ll need to make sure the account you use has Administrator privileges.
The Events that Process Monitor Captures
Process Monitor captures a ton of data, but it doesn’t capture every single thing that happens on your PC. For instance, Process Monitor doesn’t care if you move your mouse around, and it doesn’t know whether your drivers are working optimally. It’s not going to track which processes are open and wasting CPU on your computer — that’s the job of Process Explorer, after all.What it does do is capture specific types of I/O (Input / Output) operations, whether they happen through the file system, registry, or even the network. It will additionally track a few other events in a limited fashion. This list covers the events that it does capture:
- Registry – this could be creating keys, reading them, deleting them, or querying them. You’ll be surprised just how often this happens.
- File System – this could be file creation, writing, deleting, etc, and it can be for both local hard drives and network drives.
- Network – this will show the source and destination of TCP/UDP traffic, but sadly it doesn’t show the data, making it a bit less useful.
- Process – These are events for processes and threads where a process is started, a thread starts or exits, etc. This can be useful information in certain instances, but is often something you’d want to look at in Process Explorer instead.
- Profiling – These events are captured by Process Monitor to check the amount of processor time used by each process, and the memory use. Again, you would probably want to use Process Explorer for tracking these things most of the time, but it’s useful here if you need it.
The Process Monitor Interface
When you first load up the Process Monitor interface, you’ll be presented with an enormous number of rows of data, with more data flying in quickly, and it can be overwhelming. The key is to have some idea, at least, about what you are looking at, as well as what you are looking for. This isn’t the type of tool that you spend a relaxing day browsing through, because within a very short time period, you’ll be looking at millions of rows.
The first thing you’ll want to do is filter those millions of rows down to the much smaller subset of data you want to see, and we’re going to teach you how to create filters and zero in on exactly what you want to find. But first, you should understand the interface and what data is actually available.
Looking at the Default Columns
The default columns show a ton of useful information, but you’ll definitely need some context to understand what data each one actually contains, because some of them might look like something bad happened when they are really innocent events that happen all the time under the hood. Here’s what each of the default columns is used for:- Time – this column is fairly self-explanatory, it shows the exact time that an event occurred.
- Process Name – the name of the process that generated the event. This doesn’t show the full path to the file by default, but if you hover over the field you can see exactly which process it was.
- PID – the process ID of the process that generated the event. This is very useful if you are trying to understand which svchost.exe process generated the event. It’s also a great way to isolate a single process for monitoring, assuming that process doesn’t re-launch itself.
- Operation – this is the name of the operation that is being logged, and there is an icon that matches up with one of the event types (registry, file, network, process). These can be a little confusing, like RegQueryKey or WriteFile, but we’ll try and help you through the confusion.
- Path – this is not the path of the process, it is the path to whatever was being worked on by this event. For instance, if there was a WriteFile event, this field will show the name of the file or folder being touched. If this was a registry event, it would show the full key being accessed.
- Result – This shows the result of the operation, which codes like SUCCESS or ACCESS DENIED. While you might be tempted to automatically assume that an BUFFER TOO SMALL means something really bad happened, that isn’t actually the case most of the time.
- Detail – additional information that often doesn’t translate into the regular geek troubleshooting world.
One of the reasons for adding additional columns to the display is so you can very quickly filter by those events without being overwhelmed with data. Here are a few of the extra columns that we use, but you might find use for some others in the list depending on the situation.
- Command Line – while you can double-click on any event to see the command line arguments for the process that generated each event, it can be useful to see at a quick glance all of the options.
- Company Name – the main reason that this column is useful is so you can simply exclude all Microsoft events quickly and narrow down your monitoring to everything else that isn’t part of Windows. (You’ll want to make sure that you don’t have any weird rundll32.exe processes running using Process Explorer though, since those could be hiding malware).
- Parent PID – this can be very useful when you are troubleshooting a process that contains many child processes, like a web browser or an application that keeps launching sketchy things as another process. You can then filter by the Parent PID to make sure that you capture everything.
Examining a Single Event
Viewing things in a list is a great way to quickly see a lot of different data points at once, but it definitely isn’t the easiest way to examine a single piece of data, and there is only so much information you can see in the list. Thankfully you can double-click on any event to access a treasure trove of extra information.The default Event tab gives you information that is largely similar to what you saw in the list, but will add a bit more information to the party. If you are looking at a file system event, you’ll be able to see certain information like the attributes, file create time, the access that was attempted during a write operation, the number of bytes that were written, and the duration.
Switching over to the Process tab gives you lots of great information about the process that generated the event. While you’ll generally want to use Process Explorer to deal with processes, it can be very useful to have a lot of information about the specific process that generated a specific event, especially if it is something that happened very quickly and then disappeared from the process list. This way the data is captured.
The Stack tab is something that will sometimes be extremely useful, but often times will not be useful at all. The reason why you would want to look at the stack is so you can troubleshoot by examining the Module column for anything that doesn’t look quite right.
As an example, imagine that a process was constantly trying to query or access a file that doesn’t exists, but you weren’t sure why. You could look through the Stack tab and see if there were any modules that didn’t look right, and then research them. You might find an out of date component, or even malware, is causing the problem.
Or, you might find that there isn’t anything useful here for you, and that’s just fine too. There is a lot of other data to look at.
Notes on Buffer Overflows
Before we even proceed further, we’re going to want to note a result code that you’re going to start seeing a lot in the list, and based on all your geek knowledge so far, you might freak out a little bit about. So if you start seeing BUFFER OVERFLOW in the list, please don’t assume that somebody is trying to hack your computer.Lesson 4: Understanding Process Monitor
Buffer Overflows
While yes, many hackers and malware creators exploit a buffer overflow weakness to remotely or locally hack into a component and gain extra access, this error message is actually built into the Windows API and means the complete opposite.
Note: Imagine a buffer like a box of candy bars near the register in a grocery store. People keep buying them, and when the box gets low, the store fills the box again.What the BUFFER OVERFLOW message in the Windows API, and specifically in Process Monitor, actually mean is that the client application requested data but didn’t have a large enough bucket to hold all of the data. So the server is responding to tell the client that they need a bigger bucket.
Ideally they won’t wait for the box to be empty, because that would be frustrating for customers, and they also will ideally not go running to the back every single time a customer buys a single candy bar, because that would be a waste of time. This is a buffer, and they are meant to prevent delays.
In the example for the screenshot above, the application queried the registry for a specific value, but told the Windows API to put the result into a place in memory that was too small to fit all that data. So Windows returned back the message to let the application know that they need a bigger spot to put all the data. That’s all it was.
Jumping to an Event Data Path
All of this information is really great, but nobody wants to investigate by manually browsing to each and every location in the list. Luckily you can right-click on the Path field for an item and use the Jump To option to quickly access that data to see what it contains and try to figure out why the application is requesting that data in the first place.Note: you can also use the Search Online feature to quickly search for the name of the process, the registry path, or any other field, which can be really useful when you don’t understand what something is used for.
In the example above, you can see that the application we were monitoring was trying to look at a registry value, so we used the Jump To feature, and Process Monitor immediately opened the Registry Editor already focused to that exact key.
So now we know, the application is trying to figure out where my appdata folder is, and we know which folder that was… which helps explain what is going on.
In this case, the application was the Conduit search malware, and it was looking for my user folder by querying the regisry so that it could start messing around with files and folders inside of my Google Chrome profile.
Filtering the Data that Process Monitor Captures
As we’ve mentioned a couple of times already, the filters that Process Monitor provides allow you fine-grained control over what events you are going to be capturing, which translates into much easier work for you to figure out what is important in the list. If you know that you don’t care about all of the events generated by explorer.exe, for example, then you would be wise to just filter them out.You can very quickly filter by any column using the context menu and using the Include or Exclude features — if you Include an item, the list will only contain events that match that particular item, or any others that you specifically include, but will not contain anything else. If you Exclude an item, everything will show up except for events that match the very specific item that you excluded.
In this case we decided to Include the cltmng.exe process, and now every single thing that we see in the list is related to that process.
You can alternatively use the Edit Filter option from the menu, or access the Filters section of the menu to display the list of filters and edit them. You can choose from the drop-down dialogs and match by any of the available fields, choose whether the value you type into the box will be matched exactly, or just “starts with”, or a number of other options. Then you can choose whether to Include or Exclude events that match those criteria.
Just don’t forget to click the Add button once you’ve defined your filter and before you click OK or Apply, because otherwise your new filter won’t actually be activated. Trust us, this is a common mistake!
You can also remove or edit filters by selecting them in the list and then modifying or removing them.
Way Too Much Data? Try Dropping Filtered Events
If you know for sure that you have the right filters to look at just the things you really want to see, you might want to consider using the Filter -> Drop Filtered Events feature.What’s actually going on here is that the instance of Process Monitor is showing only the items that match the filter, but everything else is still being captured in the background, which can be a TON of data after a very short time — note the status bar in the example below that we had running for just a few minutes. If we had the Drop Filtered Events option turned on, it would have only captured just the events we wanted.
There is a big drawback to using this feature though, and that is that you can’t get back those filtered events if you realized you filtered the list by too much, and wanted to examine events from another process. You’d have to redo your entire scenario, which might be too late. So make sure to use this option with caution.
Saving Dumps for Later Analysis
There’s one last thing for today’s lesson, and that is the Open / Save feature that we normally wouldn’t highlight on any other application, but in this case it is really important.Imagine you are working on somebody’s really old and lousy computer, and you want to diagnose a particular problem, but the computer is just running way too slow to sit there and deal with it the entire time. You can simply run a Process Monitor scan on their computer, save the data over to a flash drive, and then load up Process Monitor on your blazing fast personal laptop and get to work analyzing what might have happened. You can even go to the coffee shop and analyze from there.
And of course, you could also just remotely talk somebody through running Process Monitor, doing a scan, saving the file, and then sending it to you for analysis. That way you don’t even have to show up and see them in person.
SOURCE : HOWTOGEEK.COM
No comments:
Post a Comment