App-V Client service cannot be started

While testing the App-V 5.0 SP2 functionality, I once came across the issue that the “Microsoft App-V Clinet” service couldn’t be started:

service-cannot-start

I found out that the there’s was an issue with the content of the folder C:\ProgramData\Microsoft\AppV\Client\Catalog\Packages\. I had one package in there, but obviously there was something wrong or misconfigured. After renaming the Catalog folder, the service was able to start. So whenever you face the issue that the service won’t start, try first to rename the folder C:\ProgramData\Microsoft\AppV\ and check if it fixes the issue. If so, you can deep dive into the subfolders/files to figure out which one exactly cause the issue.

Archive SCCM 2007 client inventory reports

If you once need to troubleshoot the inventory reports that the SCCM clients send to the MP server, create a file named archive_reports.sms in C:\WINDOWS\system32\CCM\Inventory\Temp. This creates an own xml file for every inventory that has been sent to the MP server. It will not automcatically delete the xml files, so make sure you remove the file when you have finished troubleshooting.

Virtualize Quicktime 7 with App-V 5.0

I cam across a strange behaviour after I have virtualized Quicktime 7. The following message appeared when launching Quicktime:

CoreFoundation-issue

Next step was to troubleshoot the issue with Procmon. I started it within the bubble. This is the output:

AppV5_CoreFoundationDll

As you can see, ExportController.exe is looking for the CoreFoundation.dll file in different locations (usual behaviour). The interesting thing is the selected line. Within the virtual bubble, this path is absolutely correct. The file is stored in this location. But the result of the file activity is “PATH NOT FOUND”, means the file isn’t there. To proove you that the file is located in that folder when you install Quicktime, see next screen shot:

Native_CoreFoundationDll

As you can see, the file has been successfully found, see selected line. It’s exactly the same path as before, so why was it not working before? That’s in fact a good question. I don’t have an answer on it yet. But what is clear is that the ExportController.exe tries to access the file in the right path. The problem is that the path isn’t “translated” into the physical path. It should be **App-V Cache Folder**\PackageGUID-VersionGUID\Root\VFS\ProgramfilesCommonX86\Apple\Apple Application Support\CoreFoundation.dll. Maybe it’s a bug? I don’t know, I will try to figure it out…