One of the things I talked about when App-V was going into the core of the OS was how it was going to provide new opportunities to improve App-V. And the prime example I gave was how the virtual registry worked. Well I was eventually proved right, although the transition is proving to be a bit bumpy for some folks (more on that later).
When we built SoftGrid, the original name for App-V, we kept the virtual registry out of the real-windows registry. This was done by redirecting the registry reads and writes to our own driver software that worked using files external to the registry. In some of the App-V 4.x performance testing I did back in the day I was able to show how under certain (specially concocted) circumstances, App-V could actually improve an app’s performance when virtualized over the native performance because this file access was better than that of the actual registry on older OSs.
When Microsoft re-wrote the software for 5.0, they wanted to eliminate undocumented file formats and turn to modern standards, so they integrated the virtual registry directly into the real thing. But because at that time they were not part of Windows core, the dev team was limited to the same APIs that external developers have access to. (This was due to rules implemented when the US government and Microsoft settled the anti-trust suit that threatened to break up an alleged Microsoft monopoly). Which meant that when they wanted to mount a new package’s virtual directory they had to do the equivalent of a registry import — one item at a time. They called this registry staging and tried to hide it in the background, but it still was a significant performance impact to non-persistent logons.
When I met with the dev team in November of 2015, I mentioned to them that I was hoping they would now have access to some internal registry APIs to allow them to mount it in one big swoop.
In Windows 10 1703, it appears that they have done this. Registry staging is no more. If you ProcessMonitor an App-V package launch on Windows 10 version 1703 or later, you can see this mounting occur in an event like this one:
This is a mount event of the virtual registry file of the package, done as a single event. Further virtual registry entries in the trace show the \\Registry\WC\Silo_… path being used to access individual entries. This was interesting, yet puzzling to me until this week.
In a recent blog post (in German), Microsoft’s Sebastian Gernert refers to this as a container. Hold on! It’s hard to tell with language issues if the translation is the concept of a container, or actually refers to “Windows Containers”, as in the things that Docker runs in.
We know that Microsoft added containers not only to the Server OS, but also to Windows 10 in the 1604 version. For a while the Bridges for Windows Desktop (aka Centennial) converter, for ISVs to turn Win32 apps into Windows Store Apps, utilized these containers to package things up. At the time I pondered how else we might be able to use containers and did a little skunkworks discovery. One thing that I noticed was that things running in a container, as well as AppX based apps that are “sandboxed” show that they have a JobID when you look at them in the Task Manager.
Jobs are a little used capability that has been in the OS since at least Windows NT. They were intended originally as a way to organize a collection of processes and manage them as a group. You could do things like apply quotas to the Job and kill off all of the processes in the entire job in one quick action. But they never really garnered much use. So it was surprising to see these things using JobIDs, especially since the jobs didn’t include multiple processes. It sounds to me like someone spotted a convent unused OS process tagging system and re-used the designation. But who knows.
As I said, AppX processes, and processes running in a Windows Container all have Job IDs. And now with this registry container use, so do App-V packages. Just add the column to the Task Manager and you can see them, just like the image below where AppVPersonalization.exe and AppV_Manage.exe are in App-V packages:
This doesn’t prove that containers are in use, but we at least have a whiff of smoke here. I haven’t had the time yet to test out the performance impact, but expect it to be huge when I do. But there is a down side.
The problem(s) are not very clear yet, but Microsoft seems to be working on some fixes based on difficult customer scenarios. Now I have never had a problem with the new system, but I always use fresh install operating systems (as apposed to upgrades) and only use local profiles without any user environment products (like UE-V, AppSense, Res, etc…) that might move user profiles from one system to another. I believe that people having an issue are having it due to Migration. If you had a package on an older system the virtual registry was in the registry and Microsoft has to detect this and Migrate your changes. Some things about the package are in your profile while others (like the staged copy of the registry) are in the HKLM branch. So it is likely that all the upgrade and roaming situations with all of these different roaming profile/UEM situations were not tested properly. And don’t even think of allowing a user to try to roam back!
Footnote:
It would be nice if Microsoft talked publicly about these kind of changes. Heck, even NDA conversations with the MVPs would be appreciated as we would be better equipped to help customers struggling with undocumented changes. But right now they seem to be plugging away at improvements without talking to us. I hope that changes soon!
