Process Monitor: Tips for Running Long-term Captures in the Enterprise
Process Monitor is a great tool for investigating desktop and XenApp application problems, although there are some challenges. Trace data volumes can be a concern and, with the need to start the program with elevated rights, running it on multiple desktops can seem impractical. In this article we discover how we can overcome these difficulties, and even deploy everything via an AD group policy.
We are currently investigating a problem with Word and the popular iManage Worksite Document Management System (DMS). The problem is that intermittently a new revision of a document gets saved into the DMS with a zero-byte length. The module set-up inside Word is very complex, with no less than 16 add-ins installed. Of course the challenge is figuring out which of these is causing the problem.
Microsoft's Process Monitor is an ideal tool to investigate this problem. Not only can we trace Word interacting with a local directory but also communications with the DMS application server. However, there are challenges. The intermittent nature of the problem means that we need to capture for days, if not weeks, and each time procmon is started the user is prompted for a user id and password of an account with admin rights. In the following video we discover how we can overcome these issues through the use of tight filtering to reduce the volume and Windows Scheduled Tasks to start procmon without entering admin account details each time.
Deployment couldn't be easier. The scheduled task, batch script to start procmon and procmon configuration file can all be deployed using an Active Directory Group Policy. Our customer defined a group specifically for this purpose, which meant that deployment simply meant adding users to this new group. It's important to monitor disk usage to make sure the trace files don't fill the volume, and ideally this would be done through an automated task.