Avoid Export, Delete or Reset Errors by Excluding Dr. Watson Files

Ever run into a layer that you just couldn't export, delete, or maybe even reset without an error? There can be a few different causes, such as a file in the layer being locked. But there is one very consistent, reproducible, and easily avoided cause that I've identified -- our old friend Dr. Watson.

Background

You've probably heard me speak about how SVS -- unlike other app virtualization products -- does not have it's own access control mechanism. SVS relies on and "passes through" the native Windows security model. Normally this is a good thing. It means SVS doesn't significantly alter how you manage a machine from a security perspective; your existing tools (including audit tools) work normally with the content of SVS virtual layers.

In addition, Symantec is not introducing another information assurance component into the client architecture with SVS. That allows the people who need better software management to drive the SVS adoption decision without excessive involvement from the security guys (tho of course, the involvement of security guys is never "excessive," is it... ?).

The Problem

However, it also means that SVS -- which does a lot of things that can be constrained by windows security -- has to work within the rules. And sometimes you, the logged-in user -- or the management agent that's sending commands to SVS -- may not have the permissions required to read or delete a file, folder or registry object.

So a common reason for error during a layer export, delete or reset (which includes a delete of the old writable sublayer) is a file (or some other object) in the layer that the user executing the SVS command does not have rights to access or delete. (In the case of a reset, of course, the object would have to be in the writable sublayer to cause a problem.)

These objects can be unpredictable and hard to locate. However, here's one common example of such an object that is not only always a problem when it exists, but could be an issue on any Windows PC, and is easily avoidable with a simple SVS Agent configuration change.

When Dr. Watson handles an application crash, it creates two files under [COMMONAPPDATA]\Microsoft\Dr Watson -- user.dmp and drwtsn32.log. The latter is no problem, but the former, that dump file, is ACL'd so that no interactive users have rights to it. The result: If a layer in an app crashes and Dr. Watson does his ("it's") magic, you will end up with a file in the app's writable sublayer which cannot be accessed. This will cause an Error 5 on an attempt to export the layer and will also prevent deletion (including Reset).

The Fix

This particular example is bound to come up eventually on enough machines to create a headache. To avoid it permanently, add [COMMONAPPDATA]\Microsoft\Dr Watson to the Global Exclude List in the SVS Agent config. This may be done in SVS Admin under "Edit > Edit global excludes... " or by editing the following registry key in a script: HKLM\SYSTEM\Altiris\FSL\Exclude.

If you already have a user.dmp file in a layer, you will need to edit its permissions to add full rights for whatever user or group is needed. On my own machine, now that I have [COMMONAPPDATA]\Microsoft\Dr Watson added to my global excludes, I've searched for, edited the ACL on and deleted all such files in my redirect areas. After all, Dr. Watson files aren't exactly as critical for permanent retention as someone at Microsoft apparently thought they might be...

Excelsior!