App-V 4.6 SP1 Sequencer added a lot of detection logic to help identify issues with attempted sequencings. One of those features was the detection of device drivers, as virtualizing device drivers is not supported. I have seen this feature working in the past, and assumed that I could count on it. Maybe not…
In a comment here on the blog, Sh1va asked about an issue ?he was having with an application “BBFlashback”. This application is a screen recording app along the lines of Camtasia, which I documented how to sequence in Episode 9 of my Sequencing with Tim Mangan video series.
Eventually, I got around to trying the application myself. I suspected a possible device driver, based on info from Sh1va and my experience with Camtasia. So I sequenced it using App-V 4.6SP1 with HotFix3, on a Windows 7 with SP1 x86 machine.
The sequencing report did not include notice that there was a driver. Threre were unsupported shell extensions (not a problem), reboot processing (normally not a problem), and excluded files (usually OK also). The exclusion files are usually just temporary files used during the install and log files documenting what happened, but it is always interesting to look at this list. The exclusion section of this report had a file in the temp folder named “FlashBackDriverInstaller.exe”, which is a red flag. But just because a developer calls something a driver installer in a filename does not mean it is a true device driver. Sometimes these things are just things like codecs that work just fine under virtualization because they are used by a user mode component running as part of the virtualized app. Camtasia has quite a few of these, for example.
But as I said, the report did not detect a driver. If it was a driver I expect the sequencer to detect it and it would be in the report. But there was no such entry in the report.
Looking into the captured file list in the “Sequence Editor” (that’s my name for the multi-tabbed interface where you can view the details and edit the package manually), I decided to check for the driver the old fassioned way – by looking for a file in the system32/drivers folder. Sure enough, there it was!
So why didn’t it get detected? I’m not sure yet, but obviously it pays to continue to use our old techniques and not trust the automation!
