Upon my travels I am amazed about the amount of people (techies) that I come across in the field who have never heard about Process Monitor let alone those who know about it but never use it. Now I understand that for many, this blog entry will be much to do about stuff you already know but hopefully for some innocent passer-by, I may be able to brighten their day by opening their eyes to a truly magnificent tool…
Before we continue – make sure you download Process Monitor if you don’t have it already – http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx?PHPSESSID=d926
Process Monitor is a combination of a number of tools written by Mark Russinovich and Bryce Cogswell, the 2 gentlemen behind SysInternals before it was acquired by Microsoft. Process Monitor encompasses the legacy tools Registry Monitor (aka RegMon) and File Monitor (aka FileMon) as well as including a number of massive enhancements such as powerful filtering, process information such as thread and memory and much more. Most of all, this tool is free!!
In this 3-part blog I hope to open the eyes of some ProcMon virgins and expand the use of this tool. This entry will start by examining the registry monitoring feature…
What is Registry Monitoring Good For?
One thing that is very common in shared environments such as Terminal Services or even VDI desktops is that applications often break. This is sometimes down to the fact that the developer assumed the user would have a machine which belonged to them and therefore could do anything with it, or simply that the user would be an administrator. A typical example of this is where an application uses the HKEY_LOCAL_MACHINE registry hive as opposed to HKEY_CURRENT_USER and while there isn’t always a way to directly address the problem, there are often ways to mitigate risk if you understand the problem a little better.
Let’s start with a fairly simple example – consider the following code:
#include <windows.h> int main()
{ HKEY hRegHandle = 0; if ( ERROR_SUCCESS != RegOpenKeyEx(HKEY_LOCAL_MACHINE, “Software”, 0, KEY_ALL_ACCESS, &hRegHandle) )
{
MessageBox(NULL, “Registry Error – ABORT”, “ERROR”, MB_ICONERROR);
return(1);
} MessageBox (NULL, “Success!!!”, “Error”, MB_OK); RegCloseKey(hRegHandle); return(0); }
Don’t worry too much about understanding C, or my messy code for that matter but try to follow the logic of the program through. If you do want to try the example you can compile it with something like Visual Studio or a nice little light-weight C compiler, LCC which you can get for free here – http://www.cs.virginia.edu/~lcc-win32/
Developers are inherently lazy! Sorry guys ‘n’ gals but I guess when you write thousands of lines of code you make some assumptions and take some shortcuts and unfortunately this is sometimes in the error checking department. The code above actually does have error checking in but with a non-descript message, sometimes applications have no error checking at all resulting in a nasty crash with ugly errors moaning about debugging and things…
Basically the code above attempts to open the registry key HKEY_LOCAL_MACHINE\Software with full rights which include things like read and write – later the app would probably use the registry to store information. For an administrator this code works fine and they get a nice message box informing them of a success, however for a user, we see a non-descript error:
What would have been nice is if the code included exactly why the program had stopped but that would have been a number of extra lines of code and hey, we have deadlines to meet right!!!
Anyway, from the message box provided, and without looking at the code, we wouldn’t really know what was going wrong with the program – all we know is it works for an administrator but not a user. This is where Process Monitor comes in…
If we fire up Process Monitor we are prompted with a box asking us what we want to filter – we’ll skip past this for now and return to the filter later. Once started, Process Monitor will look something like this:
Now given our error message gave us a hint about what was wrong – “Registry Error” it would probably be a safe place to start there so what we’ll do for now is turn of File Monitoring and Process Monitoring – they’re located towards the right of the toolbar. Once we’ve done that we’ll also hit the filter button (next to the font and looks like a little white triangle) so we can control the amount of information we’re receiving. Once we bring up the filter window, we will include a filter to only include our process which is called REGTEST.EXE.
Once we’ve set up our filter, we can have our user run the program again and monitor the output.
NB: While I’m writing this article I’m assuming the troubleshooting is being done on a Terminal Server and therefore I’m running Process Monitor on an admin session whilst running the bad application on the user’s session. If you want to do the same thing on a workstation, use the RUNAS command to run Process Monitor as an administrator.
When the application has been run again and the resultant error message spawned we can examine the information given to us by Process Monitor. Again we do however have some pointers for this exercise in that the application works for an administrator account but not a user and therefore is possibly something to do with permissions. With this in mind if we bring up Process Monitor and search the result field for ACCESS DENIED (use CTRL + F to find) we soon come across a couple of suspicious entries…
From this information we now know that the application is attempting to open HKEY_LOCAL_MACHINE\Software and requesting more access that the user actually has. If we then examine the permissions on the registry key we can see that standard users read abilities so therefore the application must be requesting more rights than just read.
Unfortunately there is no way to ‘fix’ the application without actually changing the code however based on what you find it is sometimes possible to limit what damage can be done whilst allowing the application to run. If this example was trying to open HKEY_LOCAL_MACHINE\Software\Vendor1 for example, you may be happy relaxing the permissions on the Vendor1 key to get the application working.
Finally, this was somewhat of a simple example of registry monitoring with Process Monitor and not all application problems are permission related. Experiment with the tool, try running it against some of your existing applications and look at what registry activity is going on – sometimes you may even find some ‘secret’ registry keys.
Until Next Time…
This post was filed in Microsoft Windows Tips & Tricks
About Jon Wallace:
Jon is a senior executive and technology veteran having worked with some of the largest and most complex technology environments in the world. As director of emerging technologies for a leading multinational software organization Jon focuses on creating disruptive strategy and maintains an in-depth view of the industry at large.
With the experience of working from the field level to the boardroom Jon brings a unique viewpoint catering for many factors and one which is based on real world experience.
Leave a comment