Archive for June 2010

Using Process Monitor to debug applications

leave a comment »

Every once in a while there comes a bug that requires the use of Process Monitor
Process monitor is great but sometimes it is difficult to correlate its event stream with the source code you are debugging.

Using it for quite some time, I don’t really read it’s help anymore, but accidentally I’ve looked into it recently and was pleasantly surprised to see  that it now supports injecting debug messages into it’s event stream using an API and there’s even a managed wrapper for this (read diagnostic tracing process monitor)
A few of my colleagues asked me for scenarios in which to use it, so I’ll describe a few from my personal experience.

I mainly used it for debugging bugs that involve the file system or registry in some way.

Example 1:

I was maintaining a real-time legacy system that was doing a series of processing on xml files. Each processing involved creating  a temporary file in a certain directory. The problem was that sometimes certain files were lost.

Code looked similar to this:

string filename = string.Format(“{0}-{1}.xml”,
DateTime.Now.ToString(“yyyy-MM-dd-HH-mm”), Environment.TickCount);
filename = Path.Combine(dir, filename);
// synchronize access to file
lock (m_cs.MainAppDomain)
	using (StreamWriter sw = File.CreateText(filename))

Can you spot the problem? I stepped through the code many times, and I wasn’t able to reproduce the bug.

After using Process Monitor I was able to spot it: the unique filename made from the number of miliseconds since the system has started is not really unique. In some cases more than 1 file/milisecond can be created, in which case the second file overwrites the first one.

Example 2:

I had to do production debugging on a system accessible via Remote Desktop (via a special Remote Desktop infrastructure), but located behind an inaccessible subnet. So remote debugging was out of the question. It wouldn’t have helped anyway for this particular bug.

I had a piece of code that was installing an X.509 Certificate which was working under one Administrator user, but wasn’t working under another Administrator user.

The error I was receiving was “File not found exception” (the filename not being found was an empty string). Exception stacktrace was ending in an internal CAPICOM library (windows library).

At first I thought it was a security issue, so I enabled Windows security auditing but no security events were being logged, so this wasn’t a security issue.

So what I did was: take the output of process monitor when code was running fine and take the output of process monitor when the code was not working.

I compared these two and it revealed that, when it was not working, code didn’t found an AppData registry values in
HKEY_USERS\S-1-5-21-218976661-61539242-33973980-1010\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\

AppData normally points to the Application Data environment folder and should have been there. Seems somebody corrupted the registry, because lots of other shell folder values were missing too and is used by CAPICOM to locate the physical certificate store when installing a new certificate.

So I manually re-created the missing values by looking at a working system, and everything worked.

So registry corruption is another good scenario where you can use it.


Written by Liviu Trifoi

June 21, 2010 at 5:42 pm