I’ve noticed lately a few people complaining that they needed to go back to the Windows 10 ADK 1803 sequencer in order to get some applications to work. Recently, a student came to one of our App-V Training Classes and brought with him a reproducible application that demonstrated the problem. Based on what we learned in the class debugging it, and additional work in my lab after, we can now fix these issues with version 1.9 of TMEdit, but first let me explain the issue.
The student came with a package of Google Chrome made with the 1803 Sequencer, and another with the 1903 Sequencer. The packages were made as identically as possible, using automation. But no matter what the client OS was, the 1803 package worked while the 1903 package would fail upon launch.
Before we debug the issue, I’ll note that my own packages of Google Chrome Enterprise have no issues, no matter what OS I sequence on. So clearly there are differences either in how he configures Chrome or in the setup of the Sequencing ,and/or Client VMs.
We started by eliminating the differences in Client VMs by having the student test on my training lab VMs. This showed the problems on my Client VMs just as he had described on his own clients.
The package could be added and published, But when the application was launched it would immediately fail with a popup Windows Error dialog shown here:
We started by comparing the files within the two packages. This was done by making copies of the packages and renaming the files to have a .zip extension and then opening them. The packages where mostly the same, with the problem package containing a few more files that looked like they could possibly be cleaned up.
We checked the Windows Application event log to see if Chrome provided more information there, and found the following:
This didn’t seem to help at the time, but actually turns out to have been related to the problem, even if it wasn’t clear at the time.
We also ran a Procmon trace to see what that might show us. The trace wasn’t helpful. If anything, it seemed to confirm that possibly the SvcHost process was the problem, but that didn’t make sense for this application. The only direct use of SVCHost for this package would be virtual services, but these were all disabled or set to manual. I guessed that the SvcHost process involved was just to play the audio for the error dialog box after the real issue occurred and was just distracting us. We needed to look elsewhere.
Even though it seemed like it probably wasn’t going to show us any errors, we looked into the App-V event logs. The Admin and Informational logs contained nothing of value. Even turning on the App-V Debug logs didn’t help. But the App-V Virtual Applications log contained an error – the third I’ve seen ever in App-V 5.x!
We compared the AppXManifest.xml files between the two packages, and found nothing significant. The failure of the Virtual FileSystem made me suspicious of the FilesystemMetadata.XML file, which supplements the zip compressed file system to provide additional features including Override-Local folders (called Opaque in the file), Empty Folders, and short names. I talked about Short Names in this post last spring. Looking at the two files there were clearly differences in how the short names were generated in the two files.
Two forms of short names are generated in both files, the standard “~1” kind and the special type that App-V will generate to ensure uniqueness. But there seemed to be more of the special type in the newer package. So I was suspicious.
The FilesystemMetadata file for the problem package had a few extra folders referenced in it. They looked like folders that probably could be cleaned up in the package; in fact they were folders that I include in my standard setups. A couple of different students used TMEdit to cleanup the problem package through removing unnecessary folders, and these cleaned up packages seemed to work.
After the class I took the packages back into my lab for further investigation. Over a glass of wine (which seemed to help) I suddenly saw the problem in the FilesystemManifest file. It wasn’t where Microsoft made up short names, but where they didn’t complete the job. Look at the short name on this entry:
Notice the folders on the Short Name of the highlighted item:
“systemprofile” is 13 characters long, not exactly meeting the 8.3 requirements!
Version 1.9 of my TMEdit package editor has now been updated to address these issues. It will scan the FileSystemMetadata.xml file for non-compliant short names and offer to fix them. To avoid potential problems at the client I opted to use a “~T” style replacement rather than “~1” to avoid potential local system folders that already have “~#” short names. Additionally, it will scan the registry for strings containing the replaced short names (sometimes COM registrations use short names) and fix those up also. The fix is available both in the Graphical editor and in the command line AutoUpdateFixup utility that uses an XML input file to configure which fixups are desired. Current subscribers to TMEdit will be able to update to version 1.9 for free. Others can buy it online here.
Hopefully Microsoft will take this info and fix the sequencer. It is probably too late to make the 1909 ADK, but perhaps the 20H1 version next year.
