AppV5 - Package {GUID} version {GUID} failed configuration in folder '%packageinstallationroot% with error 0x4C40310C-0x12

We experienced this error on a package on one of our Citrix servers in the AppV\Client\Admin event logs.  Attempting to procmon this error didn't reveal anything substantial for what could be causing this issue.  I then tried my last post to enable AppV debug logs to see if we can see what's going on.

Because this server was being used by other users the log generated a lot of noise.  I stopped the log as soon as I got the error message though, which meant the error should be at the end of the generated log.  Fortunately, you can search for the error message:

[2]06B0.2DE4::‎2016‎-‎03‎-‎30 09:41:30.817 [Microsoft-AppV-Client]Package {499ed340-c809-47dc-a533-2cdeab537e93} version {3589c28b-edb7-41d6-865d-e01c4fdd4318} failed configuration in folder 'D:\AppVData\PackageInstallationRoot\' with error 0x4C40310C-0x12. 

I suspect the first bit of hexadecimal code (06B0.2DE4) are probably an identifier for a thread or some such so I suspect if I search for just this code I can be shown all events that lead up to this error:

Looks like it.

The log up to the error:

With the error time code, I can compare what Procmon says is going on.  And procmon reports back the following (at exactly 09:41:30.815):

Procmon has the AppVClient.exe doing the following action "QuerySecurityFile" and it's looking for "Information:Owner".  So what is this the value of this property?

Hmmm...  This does not look correct to me.  From my experience, I think the current owner ends up being 'SYSTEM' because that's the account the AppVClient.exe runs under when it creates this folder.  As a hunch, I looked at a system that is operating correctly and compared it's Owner attribute:

Sure enough, on a working system the Owner is SYSTEM.  So I'll attempt to modify the non-working system and retry adding the package:

Success!  So it appears this error "0x4C40310C-0x12" is DIRECTLY related to the ownership attribute on your PackageInstallationRoot folder.  If it is anything but SYSTEM it looks like it fails.  I do not know why that attribute changed, but changing it back to SYSTEM resolves this error code.