SOLVED

Another Exclusion issue explained

MVP

I found another case of exclusion issues, this time without specifying the installation folder.

 

The Exclusion for "C:\Windows\System32\wbem\Performance" gets mapped to [{AppVPackageRoot}]  when you enter it in the exclusion list:

Capture1.PNG

 

But it looks like a file written to during monitoring is captured using a different variablization [{System}], and is NOT excluded:

Capture2.PNG

 

Leading to a problem later on when saving the package, as shown here:

Capture3.PNG

As with the previous exclusion issue, there are two problems here:

1) The way the exclusion is stored does not match how the filtering is done.

2) The save shouldn't fail. I don't know why this file caused an error, although 003 error code sounds like file not found. Except that in this case the file is indeed there when I look for it after the problem occurred.  Perhaps it was unable to open the file to look at the attributes because someone had a lock on it?  

 

I am attaching the full log file from the save.

4 Replies

Is this a publicly available app? it looks like it extends the WMI repository.

I don't remember the specific app, but it wasn't the app touching the WMI stuff you see.  This was just general back-end Windows noise.  The issue is when the noise creates a file while monitoring, but then deletes/locks it during package creation phase.

 

I think the team has a handle on the saving issue, but ultimately I would like a way to deploy preconfigured settings for the tool.  These are stored in a file. You can pre-deploy the tool in an image, but until the user is logged on and starts the tool once, the redirection folder for the app does not exist.  So I can copy it over then, but I would like to be able to automate that.  

best response confirmed by Steve Thomas (GLADIATOR) (Microsoft)
Solution

Just a note to confirm that it looks like this no longer causes the package to fail creation in the 1.2019.110 version of the MSIX Packaging Tool.

Thanks for the update! :)

1 best response

Accepted Solutions
best response confirmed by Steve Thomas (GLADIATOR) (Microsoft)
Solution

Just a note to confirm that it looks like this no longer causes the package to fail creation in the 1.2019.110 version of the MSIX Packaging Tool.

View solution in original post