{"id":2357,"date":"2015-09-30T13:32:33","date_gmt":"2015-09-30T17:32:33","guid":{"rendered":"https:\/\/www.tmurgent.com\/TmBlog\/?p=2357"},"modified":"2015-09-30T15:28:21","modified_gmt":"2015-09-30T19:28:21","slug":"the-case-of-the-misnamed-object","status":"publish","type":"post","link":"https:\/\/www.tmurgent.com\/TmBlog\/?p=2357","title":{"rendered":"The case of the misnamed object"},"content":{"rendered":"

\"\"I suddenly seem to be getting asked\u00a0by a number of software vendors to help them support customers that are using App-V.\u00a0 This is fantastic!\u00a0 Vendors that want to support App-V?\u00a0 We have dreamed of this for 15 years now.\u00a0 I am thinking that four is perhaps\u00a0more than just a blip,\u00a0maybe\u00a0it is\u00a0a trend.\u00a0 I certainly hope so.<\/p>\n

Case Introduction<\/h2>\n

This week’s vendor (I can’t mention them by name) approached me because of a problem at a customer site.\u00a0 Unlike other ISVs to approach me recently, this one wasn’t having their software packaged for App-V, but still had a problem.\u00a0 The customer was natively installing their software on the system.\u00a0 But on systems with App-V installed, their software didn’t work.<\/p>\n

The software consisted of a back-end windows service and an Internet Explorer plug-in.\u00a0 If the user was published any App-V packages that included IE plug-ins (or probably Browser Helper Objects or ActiveX components), the app broke.\u00a0 Through trial and error they had found that if they could get the customer to enable COM visibility and disable Object renaming in the sequencer for ALL of those packages, the problem went away.\u00a0 The customer wasn’t satisfied with that solution and the vendor wanted to know what was going on.<\/p>\n

I immediately suspected that the issue had nothing to do with COM visibility and everything to do with Named Objects.\u00a0 I was right.\u00a0 So what are Named Objects and just what is this checkbox \"\" in the sequencer for anyway?<\/p>\n

Sidebar on Named Objects<\/h2>\n

The kernel of the Microsoft operating system manages a variety of resources for the user mode processes.\u00a0 It does this for efficiency and\/or because multiple processes might share the resource.\u00a0 Often, the resource (not resource type) is accessed by a name, and that it what we call “Named Objects”.<\/p>\n

The most common form of a named object might be a file handle, where the name is the full path to the file.\u00a0 The process wants to open a file, but it is the Windows System cache that actually opens the file and manages what portions are currently in virtual memory.\u00a0 While file handles are named objects that you are familiar with, it turns out that App-V deals with files via the Virtual File System and Copy-on-Write subsystems, so this isn’t what we are talking about when we talk about named objects in an App-V world.\u00a0 Microsoft doesn’t really document what App-V does with Named Objects, so I guess it is on me to explain what I think it does.<\/p>\n

\"\"The image on the right is a list of the types of objects supported by the Windows 10 operating system (it is taken from I home-grown tool that I wrote that extracts the information from an unpublished kernel interface).<\/p>\n

Long ago, a lot of software applications were written for a single user desktop OS and didn’t take into account that multiple users might want to run the app on the same OS, and maybe at the same time. So when we built SoftGrid (the original name for App-V), we decided to intercept the calls to create these named objects and change the name (an operation called “remapping”). In App-V 5.x, if a virtualized process creates or opens one of these named objects, the software remaps by changing the names uniquely for the virtual environment it is running under.\u00a0 App-V enhances the name by prepending the characters “sg” followed by a long unique identifier for the virtual environment (a 16 character hash) and an underscore.<\/p>\n

Certain kinds of named objects, such as named pipes,\u00a0tend to be used more with inter-process communication and signaling,\u00a0and when that occurs\u00a0it is important that both processes use the same name.\u00a0As long as the named object is only used by processes inside\u00a0an App-V\u00a0virtual environment, the app works normally when the object is renamed.<\/p>\n

But the operating system includes all sorts of named objects created by the kernel or windows services that are part OS, so their end of these objects is never virtualized.\u00a0Over the years App-V has developed a list of these and provides a registry exclusion list that exempts certain names from remapping by the App-V client, which makes those object work.<\/p>\n

By the way, a remapping process also occurs for isolated COM objects in a package, although in that case a different dynamic CLSID Guid is created instead (there is also a COM CLSID exclusion list in the registry).\u00a0 Together, along with the VFS file system spoofing, we achieve a completely isolated virtual environment that internally works just like the native installation but can’t get messed with by outside processes.\u00a0 There is also something referred to as “side-by-side privatization” which fits in this basic category (but not for discussion today).<\/p>\n

Why we use App-V<\/h2>\n

While we don’t see many applications that cause “dll hell”<\/em> being deployed these days (most that are still in use are over 10 years old and were likely developed in-house and will need to be retired rather than upgraded), we still see a lot of applications not fully implemented for\u00a0simultaneous use on the same system.\u00a0 Most apps today, understand the concept of different users and properly implement HKLM\/HKCU and use the user’s profile fairly correctly.\u00a0 But many still fail if you put them in RDS because they don’t make use of session space.\u00a0 Still many more fail, typically with an occasional unexplained hang or crash,\u00a0if you run multiple copies within the same user session (on RDS or desktops).\u00a0 And often we want to allow the user to run two different versions of the same application, which pretty much never works without application virtualization.\u00a0 This is why we use App-V; to make the software more predictable by limiting the dependencies on other stuff sitting around and\/or running at the same time<\/strong>.<\/p>\n

But sometimes we want integration outside of the bubble.\u00a0 The rewrite in App-V 5 was precisely to create more opportunities for integration.\u00a0 Giving us more integration points (“extensions” in App-V terminology) with other parts of the OS, other applications, and the user.\u00a0 With that integration, we also have some granular controls over that integration.\u00a0 90% of the time we don’t need to think about those controls, but sometimes we do.<\/p>\n

Back to the Problem<\/h2>\n

To protect the innocent, I’ll use a different software application from someone other than the software vendor that I was working with.\u00a0 I will use the excellent web sniffing tool from Telerik called Fiddler.<\/p>\n

Fiddler, like the ISV software I was dealing with, has both an external process and a plug-in to Internet explorer.\u00a0 With Fiddler, the external process is a standard user process that can be started from the start menu rather than a Windows service, but that doesn’t matter for our purposes.<\/p>\n

Fiddler, like the\u00a0ISV software, is also completely virtualizable with App-V.\u00a0 Both work like a champ if you create and deploy an App-V package containing the software.\u00a0 Both also work great is you create a Connection Group with the package and with the other Internet Explorer add-ons.<\/p>\n

The problem with the ISV app is seen if you natively<\/span> deploy their app and use App-V for other Internet Explorer plugins.\u00a0 Both for Fiddler and the ISV,\u00a0the external process can end up running outside of the virtual environment for Internet Explorer.<\/p>\n