Video Screencast Help
Endpoint Virtualization Community Blog

Lots of registry seeks by services.exe that result in "Not found". What's going on?

Created: 30 Nov 2006 • Updated: 29 Jul 2010 • 17 comments
insession's picture
0 0 Votes
Login to vote

Q:
Peter asks: I have one of let's say 10 app layers activated, and using Regmon shows that there are LOTS of reg seeks by services.exe that result in a "Not found". Wondering what's going on, and how I can stop these many reg seeks.

A:
One of the design principles of SVS is to keep the technology as small and unobtrusive as possible. So in the original release, we chose to pass through registry lookups rather than trying to "proxy" or "cache" them. The only way for this to work was to recursively search every active layer when a process tried to read or open a key. That's why you see what you mention above.

In practice, we observed that a different approach was necessary to be performant. In SVS 2.1, Altiris has implemented a registry cache. The result is a slightly more complex design, but a design that preserves the registry performance of native Windows. This one change resolved all of the performance-related support issues that we had with SVS 2.0.

You can check out the improvement for yourself with SVS 2.1 Beta 1!

Comments 17 CommentsJump to latest comment

insession's picture

Thanks a bundle for answering and resolving the issue I raised - works like a charm with the new SVS Beta 2.1.

Wondering if it's ok to ask the following question here:

Let's say I have 80 or so applications installed on my XP SP2 SVS 2.1 notebook - to what degree is it feasible/advisable/sensible to have all those apps installed thru SVS, maybe including AV (mine is NOD 32) and firewall (mine is outpost)?

One of the things I have taken note of is that I cannot install a new layer as long as some layers are active - which would mean that if I have 80 apps installed thru SVS, I would have to de-activate 80 layers before I can install a new one?

Thanks,

Peter

0
Login to vote
Scott Jones's picture

Of course, we love to see anyone make the wholesale transition to SVS! :)

Since SVS is such a new concept (and, honestly, because of the performance issues with 2.0), so far what we're seeing is customers going virtual with just some apps, where SVS solves specific pain points (usually a conflict issue or a major supportability challenge). But we do have a few customers who have started the total transition, and we expect to see a lot more of that in 2007.

Personally, I've been 100% virtual since some time in mid 2005. But even in my "perfect" implementation, there are certain things that should be in the base with Windows -- mainly, the unsupported software types (OS components, anything with a driver and server apps). But also management tools that by their nature need a neutral, non-virtual view of the system.

A-V products almost always use a filter driver (like SVS); so even tho they often appear to work, there are two issues. First, drivers aren't officially supported in layers. Second, more importantly, think about the purpose of A-V -- you want it to affect the base (or the appropriate layer) when it quarantines or cleans a virus. You don't want to virtualize the changes that a virus scanner makes -- you want it to really make the changes. So put it in the base and add it to the Ignore Process list (see this).

Client firewalls often use drivers as well. I know that Outpost does, to provide pre-boot protection. I haven't tested 4.0, but I did test Novell Client Firewall 2.0 (which was Outpost 2 underneath), and it appeared to work fine in a layer. But of course Outpost does a lot more than just allow/deny network traffic. It also does a lot of content management, which -- just like your A-V product -- you want actually affecting the real system, not a virtual view of the system.

So... The total vision (with SVS 2.x) is to have the following in your base:
- the OS
- OS patches
- drivers (and apps containing drivers)
- management agents
- security scanners and audit tools

...and everything else in VSP's.

[There are use cases for putting some of these in layers, like evaluating or testing software. I'm referring here to software that you want permanently deployed.]

As SVS evolves, we'll lift the limitation on drivers and will support server apps, and of course we have the Virtual Patch thing coming down the road (as a temporary state when deploying OS patches; and eventually merge them into the base).

So dive in and let us know the result!

Scott Jones
Business Critical Engineer, Endpoint Virtualization
Symantec Corporation
www.symantec.com
 

+4
Login to vote
insession's picture

Thank you much for your quick and extensive reply, Scott.

It makes sense of course to have AV and FWall in the real system.

I was more wondering how stable/functional it is to have let's say 80 layers running, especially considering the following issues?

In your system, are you saying that all of your apps are in VSPs? Would that imply that every time you install a new app, you deactivate let's say 50 or more layers?

And lastly, what percentage of those layers are inactive, and only get activated when needed? Would there be good reason to do so, or is it just as well to keep 80 layers active all the time?

And very lastly, I see that often when I install a layer/app, the folder used by that app (under flsrdr) will hold many, many pieces of data and information from other apps, that don't seem to relate at all. I wonder why that is, and how one can avoid that, as it uses lots of space on disk. For instance, a O&O Defrag installation produced 35MB of Firefox cache in its fslrdr directory structure, among many other entries. I am concerned that this would get out of hand with dozens and dozens of layers, and wonder how to install a layer 'cleanly' so as to not take along other app's data and stored files...

Thanks much for answering my many questions! It's greatly appreciated. I am a big proponent of SVS, and am spreading the word daily.

Peter

+1
Login to vote
Scott Jones's picture

1 - The question about deactivating layers to do a capture is now covered here.

2 - I usually have about half of my layers active and half inactive. The inactive layers represent two types of apps -- infrequently used, and previous versions where maybe I'm not completely sold on the new version yet.

Several people have commented that they see value in keeping infrequently-used apps a click away in inactive layers, w/o always bogging down their system's registry with their baggage as with conventional installs. (This can be especially true for very complex and registry-heavy report building products that are only used once a month or once a quarter.)

3 - Depending how the 3rd party defrag tool accesses the file system, it could conceivably make a duplicate of every file on your drive when running from w/i an SVS layer. Only one other person has told me they tried this, and it worked normally for them. But they tried it with the Windows defrag.exe, which apparently uses a specific defragmentation API provided by MS for this purpose. In that case, SVS has no affect. But if the 3rd party tool does "File Open for Write" calls to the Windows I/O Manager, SVS will make a copy in the tool's own layer. No defrag tool should have to do this (but then neither should an A-V scanner, yet Symantec does -- which is why we put the Symantec engines on the default Ignore Process list for you)!

I'll bet that's the issue with O&O Defrag, and the Firefox cache (being a good candidate for fragmentation) probably got opened for write when being moved. Have you had this problem with any other apps?

Scott Jones
Business Critical Engineer, Endpoint Virtualization
Symantec Corporation
www.symantec.com
 

-1
Login to vote
insession's picture

Scott,

Thanks for your answer here. I have deleted the O&O layer, closed all progs, reinstalled it into a layer, and the stray copies of other program files were gone. I did have this issues with another program before, but I confess that I don't recall which one it was. So from my experience, it seems to help to not have other progs open that do a lot of writing to disk when creating an app layer.

Peter

-3
Login to vote
knightnet's picture

I'd like to add something here from my own experiences.

It is an absolute pain to have to deactivate layers to install a new one. HOWEVER, there is a good way around this and it solves another issue too.

I now always install new layers to a clean virtual machine and then export and import to the live OS. This ensures that my layers are always clean (I have a template layer with my standard excludes which also helps) and the import process does not need the other layers deactivating.

This means that I can carry on working normally whilst doing new product installs.

Julian.

Julian

+1
Login to vote
insession's picture

Great comment Julian. That means, however, that the vm has to be an exact replica of the main os, in order to avoid any conflicts after importing the clean layer into the os SVS - no?

-4
Login to vote
Scott Jones's picture

Ref: "the vm has to be an exact replica of the main os"

Not at all. The rule of thumb for a package-building "Clean Machine" is that it should have the most minimal installation of the oldest version of Windows that you expect the app to be used on.

If you want dependencies in the base during capture, as discussed here, you may need more/newer components (especially when the dependencies themselves have dependencies). And of course if you are using Wise Package Studio, it has all sorts of dependencies that have to be added to baseline Windows. But regardless, the point is the machine should be as bare bones as possible.

Personally I use a VM with original release XP and no optional components. SVS Admin itself has no dependencies, so works fine on such a machine.

Scott Jones
Business Critical Engineer, Endpoint Virtualization
Symantec Corporation
www.symantec.com
 

-4
Login to vote
knightnet's picture

I agree Scott though I tend to keep by "clean" base up-to-date with OS patches.

I fact, my "clean" base isn't entirely clean but that is my lazyness at not wanting to build yet another VM!

I am only interested in WinXP Pro so different OS versions is not really an issue for me though I can see that it would be problematic if you really had to support significantly different versions.

As for WPS, I'd love to make use of it but can't justify the cost at present as I am mainly using my family as a testbed for getting to know SVS better! I don't really get "hands on" so much these days professionally as most of what I do at work is about IT architecture and project trouble-shooting. SVS is a great tool though and I will certainly be looking for more opportunities to make use of it.

J.

Julian

0
Login to vote
Kamilion's picture

I've seen this happen several times -- and the culprit is usually installers opening a Web page for a readme, release notes, or other data. Likewise, a lot of InstallSheild based programs seem to leave IE History and Cache files behind in layers. I tend to go through and prune new layers and add exclude and delete entries right away if necessary.

-1
Login to vote
insession's picture

That makes sense, Kamilion, but always adds extra work to the quick layer creation, especially when one is not sure if that layer will be a permanent one...

-7
Login to vote
tfronza's picture

I personally have two Clean Machines
1. with base XP install and all patches
and
2. with base XP install and all patches PLUS Office 2003 plus patches (in case the application I am building has Office Hooks)

Thanks - Tom Fronza

-2
Login to vote
Torlask's picture

Thank you for the great explanation about what to virtualize and what it is better to install directly in the base.

What about .NET Framework? Do you consider it a "OS patch" and so you do install in the base or whatever?

I have to install some application that depends on it and I would like to avoid to install the .NET framework in each layer for each application...

It is the usual dependency issue, how do you think it is best to solve it?

Best regards

Andrea

-1
Login to vote
Scott Jones's picture

We haven't found any issues with .NET Framework that would cause us to classify it as an OS component. It works in a layer, and is supported. In fact, we've been using it internally since early alphas of SVS; many Altiris products have .NET dependencies, but a lot of the tech folks here (including myself) don't like having it -- and especially multiple versions of it -- installed all the time. So we have the required versions handy in layers and just activate them when absolutely needed.

Scott Jones
Business Critical Engineer, Endpoint Virtualization
Symantec Corporation
www.symantec.com
 

-1
Login to vote
bsuggs's picture

It's great to hear you say .NET Framework is supported. Currently under the best practices link is shows .NET 1.1 as unsupported.

-bsuggs

+3
Login to vote
Scott Jones's picture

No, it doesn't ... :)

Scott Jones
Business Critical Engineer, Endpoint Virtualization
Symantec Corporation
www.symantec.com
 

+4
Login to vote
Torlask's picture

To sum up:
- I can install without any issue the .NET Framework in a layer
- To use .NET Framework in a layer with an application that requires it, I can:

  1. Install .NET Framework in the base
  2. Install .NET Framework in each layer of application that requires it
  3. Follow these steps:
    1. Install .NET Framework in a layer
    2. Create a VM with VMWare, with OS clean AND the .NET Framework (and SVS, of course)
    3. Install my application that requires .NET Framework
    4. Create a package
    5. Import the package in my environment (so, .NET Framework is up and running in another layer and the application is already installed and it doesn't ask me to install it)
  4. Wait for SVS 3 (dependecy management implemented)

Is this right?
Thank you!
Andrea

-2
Login to vote