Issue Thin-App with FS-logix container enabled - bluescreen

[unitifree]

Dear,

We have an issue with VMware Thin-App and FS-Logix application (only if "Profile Container" vhdx is active)

You are directly disconnected from the session when you start the thin-app application. Once we take a closer look at the virtual machine, it is in bluescreen

Here the mechanism of FS-Logix container is to create the vhdx but also to make a redirection of the different path which must be taken in the vhdx or not.

We know that since last year with an update of Windows, we had to switch to a new version of thin-app which solved the issue of old application on Windows10 20H2.

But I am still stuck with the cohabitation between thin-app and FS-Logix Container. 

Have you already encountered the same problem?

Regards,

Christophe,

[DCasota]

Msft 20H2 Update KB4592438 blocks VMware ThinApp.

Can you post the bluescreen code?

[unitifree]

Thanks DCasota for your reply.

unfortunately we do not have an error code.

Just the screenshot of the bluescreen. And as the machine restarts, it is destroyed by the push of the image

 

[DCasota]

The 'what failed: mrxsmb20.sys'-first-help indicates to a similar issue here. Do the machines (laptops/vms) with FSLogix Profile Containers run with W10 Offline Files ? 

[unitifree]

The KB is referring to the Microsoft update that effectively blocked all our thin-app applications on Windows10 20H2 but VMware released a new version of the thin-app this year. We did some tests to migrate our applications to the new version. The problem has been solved, the thin-app applications work perfectly well.

On Laptop/workstation, the offline file is enabled and no issue with Thin-app (Only force the migration to the new version for compatibility of Windows 10 20H2)

On VDI image, the offline file is disabled.

Here I think it is about the subtlety of using FS-Logix on our image with Thin-app.

In the first case, we disabled FS-Logix completely and everything was normal.

In the second case, we activated only "Mask application" of FS-Logix and everything was normal too

In the 3rd case, we have activated also "Profile Container".
There is a configuration file "Folder Redirection" which allows to restrict what is taken from the VHDX.
And with this the Thin-App application tries to open but directly the Blue Screen.

Here we confirm the good integration between VMware and FS-Logix but we have no info with Thin-app. ==> Integrating FSLogix Profile Containers with VMware Horizon | VMware 

Here we see that on the site of FS-Logix we speak well of the cohabitation between FS-Logix and Thin-app / App-V but no real information on the possible configurations. ==> FSLogix 2.0 - Rorymon.com

[unitifree]

See my test on VDI with the last compilation of Thin-App in Windows 10 20H2, it's work when the FS-Logix container isn't enabled.

In my test, I'm log with a account. this is a local profile so the profile container isn't enabled.

 

 

[DCasota]

You say that 'mask application' not, but 'profile container' drives to a bsod. There were some bsod issues in the past with the FSLogix frxdrvvt.sys which starts to handles profile redirection to vhd(x). It might be related to an I/O stack issue mentioned here.

[unitifree]

Thanks for your reply

I test to put the value by GPO. The value has correctly defined on the image. same result with same previous bosd.

[DCasota]

No clue, but good to know that the bsod it is reproducable. I would file an SR.

For the Thinapp package you could specify a different log storage directory to easier collect the logs, see reference guide. Try to collect the FSLogix + Windows logs, too. 

What happens when the ThinApp packages are not preregistered and started manually? What happens when disabling Thinapp GPO? 

[unitifree]

If the thinapp packages aren't preregistered, you are a board effect later. (in the image with FS-Logix "Profile container" is enabled)

For example with the simple program Notepad++, it's start but when you open a file direct you are a bosd. Another application you are direct the bosd. And I try to connect on the virtual machine but I don't have the time to try to log on the VM with the bosd, it shutdown directly by Horizon.

It isn't possible to give the log of FSLOGIX or Windows logs because the VM are destroyed after 1 minute by horizon.

In the pool of image with FS-Logix profile container is enabled, we can't apply a GPO to register the thin-app.

I use only a cmd file with this

"\\Path\Win10-20H2\thinreg.exe" /r "\\Path\Win10-20H2\Notepad++\Notepad++ (ThinApp 20H2).exe"

I check to specify a different log storage folder.

[DCasota]

Can you reproduce the issue constellation on a laptop/workstation 20H2 with FSlogix Profile Container enabled?

[unitifree]

As discussed earlier, I can repeat this mistake all the time. In every image with FS-Logix "Profile-Container" activated with all thin-app application.

[DCasota]

Thinapp is yet another application virtualization solution for non-cloudnative apps on Microsoft Windows XP+W7 which weren't refactored or substitued. I like Thinapp. The product plays nicely for those scenarios and still supports newest W10 x86_64 os flavors.

A prerequirement always was that the Thinapp registration&entrypoints are not blocked by [fill in your masking solution set].

FSLogix Profile Container is just yet another storage container solution on Microsoft Windows x86_64. What I've understood so far is that it is same FSLogix rule set in W10 1909 and 20H2, right? So there is "white masking" for thinreg.exe and the thinapp packages entrypoints.

As a customer it is somewhat annoying to collect support log files and much more complicated in cascading tech setups.

If you cannot drill down the SMB prerequisites for \\server1\share\thinreg.exe "\\deployserver1\thinapps\my Notepadd++.exe", try to involve a network admin. server1+share should be accessible in your scenario from W10 1909 or W10 20H2 desktops. If it is a localsystem account issue aka "no network" to the particular time of entrypoint registration, involve a system engineer.

If the name length of Thinapp packages entrypoints or special characters in Thinapp entrypoints is an issue, avoid that.
If you cannot do a dev build of the Notepad++ example just showing the debugging entry points cmd.exe+regedit.exe and register just those for testing purposes, try to involve a Thinapp admin.

If you cannot save the logfiles because you cannot change the horizon pool setting "delete desktop on logoff", try to involve the horizon admin.

Might contain some starting points. Hope this helps. Daniel

[unitifree · Accepted solution]

I thank you for your answer, here I understood that you did not really have a solution to propose to me and gave me a check with a broad vision.

1. FSLogix Profile Container is indeed only a container. FSLogix Mask application is useless for a thinapp application as we can apply a security group in the settings.

2. At SMB level with the fully qualified name, we have no problem because here the problem is not SMB but only application launch because as explained it works without FSLogix.

3. At the level of the application names we do not exceed 14 characters with extension included.

5. It is impossible to go into a virtual machine, if Horizon Server detects an anomaly with the vm it restarts it automatically

The final solution was found after several searches.
No change of setting in horizon server, pool or FS-Logix

Only on the level of ThinApp. There is a very important and mandatory setting

The parameter SandboxPath=c:\temp

With this setting after compilation, the applications are fully compatible with FSLogix (Thinapp 5.2.9 important for Win10 20H2 and FSLogix Apps 2009 HF_01)

[DCasota]

Hi @unitifree , in fact caring about ThinApp sandbox content is an architecture task. Aligning the per-ThinApp package sandbox path with a valid FSLogix profile container exception path didn't cross my mind indeed. Thank you for sharing your findings.