App-V 5.0 SP3 Sequencer issue

There is a bug with the App-V 5.0 SP3 Sequencer that has just been release some days ago. When you try to install the MSI of a created App-V package created by the SP3 Sequencer, the installation only works when you run the MSI installation in an elevated cmd (start cmd.exe with “Run as Administrator”). If you deploy your apps with SCCM, you’re usually not affected when you run the installation by the system account.

The following error messages are shown when you install the msi without elevated cmd:

error1 error2

I created an mst that fixes the issue. Do the following steps to apply the fix :

  1. Download the mst that fixes the issue:
  2. Extract the mst file and copy it into the same folder as your msi file
  3. Run the following command:
    msiexec /i YourAppvPackage.msi TRANSFORMS=AppV5_SP3Fix.mst

If you want to run it unattended, add /qb as parameter. Make sure your current directory is the one that contains the msi/mst or just add the full path to your msi and mst. Don’t rename your msi, use the original name that has been created by the sequencer.

You can also permanently apply the transform (mst) to the msi with Orca.

The root cause of the issue is a changed setting in the MSI. The custom actions responsible to publish and remove the App-V package won’t run under the local system account with full privileges (no impersonation)


The mst I created changes that configuration back so that these custom actions run under the local system account with full privileges (no impersonation) as it was prior to SP3. This change is done by changing the above marked type values from 1025 to 3073.


GoPro Importer causes high CPU usage

I bought the new GoPro Hero 4 Black edition camera in order to make some recordings during my Australia trip that will take place the whole January 2015. After installing GoPro Studio, I observed a constant high CPU usage (20-50%) caused by WMI Provide Host. That high CPU usage was caused by GoPro Importer. It’s a startup executable that constantly checks if the GoPro cam has been plugged into the computer. After having removed it from the startup list, the issue disappeared.

ACL issue on user-published App-V 5.0 SP2 packages

There is a known issue when you publish an App-V 5.0 SP2 package user-based. The issue will be seen when it’s published to roughly ~250 users. This can be observed in the eventlog:

Part or all packages publish failed.
published: 3
failed: 1
Please check the error events of ‘Configure/Publish Package’ before this message for the details of the failure.
Event-ID: 19104

The issue happens because every user that got the app published has been added to the ACL of the published App-V package below c:\programdata\app-V reaches its limit (~250 entries) and therefore the whole publishing mechanism doesn’t work properly anymore. The reason is the PSAC feature (Package Store Access Control) that is depreciated and won’t exist anymore in App-V 5.0 SP3 that will be released soon. So SP3 will fix the issue. In the meantime, the following workarounds exist:

  • Publish the app globally and not user-based
  • Delete the cache
  • Run a scheduled script that will reset the permissions on the folder

Thanks to Sebastian Gernert who posted about the issue (it’s in German):

App-V 5.0 SP2 HF5 on Windows 10

Already tried using App-V 5.0 SP2 HF5 on Windows 10 Technical Preview or are you just before trying it? If yes, make sure you have at least installed Build 9860. There is a known issue with junctions. App-V 5.0 uses junctions, i.e. in “C:\ProgramData\Microsoft\AppV\Client\Integration”. You will get an error message when launch an App-V package thru the shortcut in the start menu because the file that is part of a junction folder cannot be found.

Other than that, App-V 5.0 SP2 HF5 worked perfectly on Windows 10, I haven’t experienced any issues so far with my packages….

App-v app knows its real path

Ever wondered what is being returned if a virtualized app in App-V 5.0 asks for its own path? I tested it with a simple C++ exe that I created for that particular case. It uses the GetModuleFileName API to get its own path on the system. When running the exe, the output is its path and the directory listing of the folder it’s located in.

I created an App-V 5.0 package with the exe twice in it, once in the VFS and once in the PVAD path (PVAD = c:\getPathOfExe):

– c:\getPathOfExe\getPathOfExe.exe (PVAD)
– c:\Program Files\getPathOfExe\getPathOfExe.exe (VFS)

There is nothing else in the App-V package than these 2 files.

So to finally test the behavior after having added and published the package, I opened a cmd.exe within its virtual environment and did run both of the exe files.

Running getPathOfExe.exe in PVAD:

Right after running the exe, you see the output of the exe’s path itself. Although it has been installed to c:\getpathofexe\, it knows that the real location is in c:\programdata\app-v\…

The next output is the directory listing of the folder it’s located in. It automatically merges with the local folder c:\getpathofexe\. C:\getpathofexe\hahahaha\ exists on my system, so it merges the folder absolutely correct. Additionally I created the folder “test” within the virtual environment which is also shown as it should.

Running getPathOfExe.exe in VFS:

The behavior is the same in PVAD and VFS. GetPathOfExe.exe recognizes that it’s located in c:\programdata\app-v\… and not in the VFS c:\program files\getPathofExe\.

In the App-V package I configured to merge c:\program files\getpathofexe\ with the local folder, that why you see the folder “hahaha” shown in the directory listing. “test” folder has been, like in the PVAD test before, manually created within the virtual environment. Directory listing works as expected.

What is the take away of the lesson? Files running in a virtual environment exactly know their “real” location.
 not working

To troubleshoot Citrix issues, I often open cdf traces with CDFControl, a Citrix tool. Unfortunately I discovered that is currently not responding (time out). You need that to download the Citrix symbol files. According to, Citrix is aware of the issue and works on bringing the server back online. Be patient….

19.09.14: Solved, it’s back working!

Adobe Reader’s Z@….tmp files cannot be deleted

Recently Microsoft provided me a private hotfix to fix a bug in the Windows Server 2012 OS (see one of my previous posts). The fix worked great, but after a day having it in production, a new issue appeared. Since we applied the hotfix, some users started to complain that a login isn’t possible anymore. It was immediately clear, this most probably is a side-effect of the applied fix. We configured our XenApp servers the way that the users’s temp folders are located on d:\temp\%sessionid%. This folder usually gets deleted when a user logs off. Additionally in the login script we check if the d:\temp\%sessionid% folder already exists on the server and if so, we try to delete it. If the folder cannot be deleted, the user will be automatically logged off during the login. You might ask you why we do that. The reason is that we didn’t want to have temporary files of a previous user in another user’s temp folder. There is not just a security reason behind, but also a potential issue that might appear if the users starts an application that wants to create a file that already exists and cannot be changed (i.e. Lotus Notes creates such issues). Therefore we decided that we want to have a clean temp folder for every user.
Knowing that, we knew that there must be something that still remains in the temp folder of a previous user that cannot be deleted. It was Adobe Reader that created Z@<something>.tmp files that were still in use by the SYSTEM process and couldn’t be deleted. Even a tool like handle.exe from Sysinternals wasn’t able to release the handle. Only a reboot of the server indeed released the handle and the file could be deleted. This brings us to the next question. Why is deleting those files not possible anymore after the hotfix? I monitored Adobe Reader and figured out that Adobe Reader still uses a Windows API that is no longer supported by Microsoft after Windows XP! This is one of the Windows API calls when I was printing some PDF pages:

CreateScalableFontResourceW ( 0, “C:\Users\michi_000\AppData\Local\Temp\acrord32_sbx\Z@SC8AF.tmp”, “C:\Users\michi_000\AppData\Local\Temp\acrord32_sbx\Z@RC89E.tmp”, NULL )

Check out to get more information of that function. There you can find that end of client support is Windows XP and end of server support is Windows Server 2003. So again, Adobe uses an API that isn’t support since XP/2003 server! And the private hotfix has somehow changed the behavior of that API that Microsoft won’t support anymore.

Maybe you observed that the temp folder in the example above isn’t d:\temp\%sessionid%, but instead the default one. Correct! The reason is that I was even able to reproduce the issue on my Windows 8.1 with the latest Microsoft Updates. This made me thinking about updates. And indeed it now looks like that all Windows clients and Windows server OSs with the latest Windows Updates will be able to reproduce the issue! So which update is it? Honestly writing, I didn’t remove the update to proof it is this one, but it’s very obvious. Check out this security update:

Read “Known issue 1” and you exactly read what you experience! So what does this mean? Adobe has to recode Adobe Reader and should use another API that is supported and doesn’t produce the same issue. This is not a Microsoft issue, this is an issue that has to be fixed by Adobe.

Maybe you also came across that post:

It’s an older post, but still valid and reflects the issue. The option with the ini file still works with the latest Adobe Reader version, but this isn’t an option for me as this will have an impact on the quality of the printouts.

To sum up – Adobe has to recode Adobe Reader. The CreateScalableFontResourceW function is outdated and not supported anymore. I was able to proof that this API doesn’t release the font file anymore after it has been executed.

Kernel debugging on a VM with WinDbg

In case you need to debug the kernel on a VM running on Hyper-V, this is how you can do it with a Windows Server 2012 R2 VM Generation 2:

  1. After the VM has been created, a COM port is needed. By default, you cannot create a COM port with the Hyper-V Manager UI. That’s one of the differences between Gen1 and Gen2. You have to use Powershell to get your COM port. First of all shut down the VM and disable SecureBoot (replace YourVMName with the name of your VM and make sure you run all commands with “run as administrator”):
    Set-VMFirmware -VMName YourVMName -EnableSecureBoot Off
  2. Then create the COM port as follow:
    Set-VMComPort -VMName YourVMName 1 \\.\pipe\DebugIT
    The “1” is the COM port you want to use (feel free to adjust it if needed) and the pipe path. The last string of the pipe can as well be adjusted, you could use something else than DebuIT.
  3. Start the VM
  4. Enable debugging:
    bcdedit /debug on
    bcdedit /dbgsettings serial debugport:n baudrate:115200
    where n is the port number defined in step 2.Reboot the VM.
  5. Open up WinDbg and choose File –> Kernel Debug
  6. Configure the COM connection according to the screen shot:
    Port: \\.\pipe\DebugIT
  7. You will see “Waiting to reconnect…” afterwards. That’s ok because we haven’t started yet debugging. Choose Debug –> Break (or Ctrl+Break). That’s it, you’re now able to debug the kernel of the running VM:windbg_localdebug-connected