For this post, I have to give some credit to someone else. But I should not name the person because they didn’t realize that what they did should not have worked. So, thanks to this unnamed accomplice!
We all think that we ‘know’ that you can’t use application virtualization to virtualize device drivers. Thus, attempting to virtualize Process Monitor, which includes a driver, should be a fool’s errand. They should have never tried to package up Process Monitor into an MSIX package. And yet it worked. I just had to dig into this.
The normal restriction
Normally, application virtualization, whether it be MSIX, or App-V, or any of the layering products out there, are perfectly willing to capture the files and registry items associated with a driver being installed. But when you deploy such packages on another system, only the virtualized environment can see those registrations and so the system does not know to load up the driver.
Under App-V, we have scripting that can run at the system level, so with many of the apps containing a driver we let App-V deal with the normal app stuff, but use a package script that installs the driver natively. This requires that the vendor has an actual driver installer that we can pull out. But MSIX can’t do that even when an installer exists.
Why is Process Monitor Different?
Process monitor consists of a single exe file that we need in the package. It really doesn’t have an installer. When you open up the zip file that you get from Microsoft SysInternals, you’ll see a number of files but the only one we need for the package is the 64-bit exe (assuming, of course that we intend to use on x64 systems).
When you start Process Monitor, it consists of the GUI that you see, plus a filter driver that records all of the file and registry transactions. Launching the exe, we can examine the activity that occurs by using other tools, like xperf for example.
The GUI checks to see if the filter driver is loaded into the system, and if it is not it will open up the resources section of its own exe file. WinPE files (like exe and dll files) have a resources section which may contain files. Traditional and Xaml dialogs, icons, and other files may be stored here. Process Monitor also stores the Filter Driver (a .sys file) in the resources section.
Process Monitor then copies the filter driver (currently PROCMON24.sys) to the C:\Windows\System32\Drivers location (outside of the package), and then invokes a kernel API to load the filter driver. Loading the driver requires system level permissions, but because Process Monitor will already be running elevated this is not an issue.
Once the filter driver is loaded, the Process Monitor GUI can start the capture, and even under virtualization it works.
When the Process Monitor GUI is shut down, it leaves the filter driver in memory (just not capturing). This could be because they decided that if you are looking for a problem, you might just come back for more. But the standard two methods un unloading a filter driver seem to now work against the Process Monitor filter driver, so maybe that is the real reason. The filter driver typically remains in the system until you reboot.
The file location used to store the filter driver is actually outside of the package itself. Thus, if you were to shut down the GUI you are able to uninstall the package, as it has no knowledge of the temporary file.
Bottom Line
Is it necessary to package up something like Process Monitor that doesn’t even have an installer? Probably not. Oh, I suppose that you could make a case for packaging it up with a shortcut and preconfigured for the capture filters and/or altitude of the driver.
The point here is that there may be techniques to put applications with drivers, especially filter drivers and plug-and-play drivers into MSIX packages.
While leaving the driver loaded when you uninstall seems to cause no harm with Process Monitor, it you try this with other apps with drivers, you should probably use the PsfLauncher with a end script to unload the driver.
Extra Credit
Other Microsoft SysInternal are fare game for MSIX too. Most like Process Explorer, just call un or under documented kernel APIs and don’t have a driver.
Happy Packaging!
