Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

UWP apps not launching with fs redirect minifilter

ntdeveloper31ntdeveloper31 Member Posts: 16

Hi Folks,

I've written a classic cross-volume file system mini-filter driver that redirects all I/O requests from one volume (C:) to another (say, T:). The basic aim here being - to ensure that the system volume i.e. C: doesn't get modified in anyway once the software (of which the driver is part of) is up and running.

I obviously do this by reparsing all the traffic from real volume i.e. C: to throw-away volume, let's call it T:. I've tested the mini-filter driver heavily. I ran it against software such as MS Office, MS Visual Studio, CodeBlocks etc. and it seemed to be working as expected as in all the I/O requests were redirected to volume T:, kept data on the system volume intact and all of this activity was transparent to the applications.

But during my testing, when I tried to launch UWP applications such as Calculator, Windows Photos etc. they just won't get launched. When clicked on a tile on task bar e.g. the calculator process gets created and it tries to initialize itself (I can see a calculator-sized blue screen coming up on the screen) but then it simply disappears without displaying any error information.

After reading up about UWP applications and how they are hosted inside AppContainer, I realized they run in the context of package sid which is different from the sid of logged on user. And the manner in which I was creating directories in the driver (with the default security descriptor) as and when they were accessed also did not help since that was basically resulting into apps receiving STATUS_ACCESS_DENIED error code. To get around this, I gave "ALL APPLICATION PACKAGES" and "ALL RESTRICTED APPLICATION PACKAGES" Full-control at the root of the throw-away volume and set "applies to" setting to "This folder, subfolder and all files". Now when the UWP app is launched, it should have access to all the directories created in the alternate locations since all of those directories now have inherited "ALL APPLICATION PACKAGES -> FullControl -> This folder, subfolder and all files" setting. But still the app fails to launch without displaying any error information.

After spending quite a bit of time investigating this, I came across this --> https://support.microsoft.com/en-ie/help/2798317/microsoft-store-apps-fail-to-start-if-default-registry-or-file-permiss
It basically says, The "All Application Packages" group (a well known group with a predefined SID) must have specific access to certain locations of the registry and file system for Microsoft Store Apps to function properly.

It looks like, giving full-control to ALL APPLICATION PACKAGES group won't do any good. It needs to have exact/specific access rights on each directory for the UWP apps to work?

Has anybody come across this/similar kind of issue. Any ideas as to how one can get around this ?

Thanks

Comments

  • ntdeveloper31ntdeveloper31 Member Posts: 16

    Here's the event I see in the event logs:

    Activation for Microsoft.WindowsCalculator_8wekyb3d8bbwe!App failed. Error code: Unknown HResult Error code: 0x80040905. Activation phase: COM App activation

    Event ID: 5961

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,142

    No specific wisdom to share, only that debugging store apps is painful (we've had problems with them in the past with our encryption filters). I'd run a ProcMon trace in the working and non-working cases and see if anything jumps out.

    -scott
    OSR

  • ntdeveloper31ntdeveloper31 Member Posts: 16

    Hi Scott,

    It is indeed quite a struggle to debug store apps.

    I did run a ProcMon trace in the working and non-working cases - but it didn't reveal much apart from calculator process exiting abruptly. The process exit status of 15612 also doesn't say much about the kind of failure. I also ran FileSpy trace in the working and non-working cases, and that's how I actually got to know about the issue related with the permissions (mentioned above) but apart from that I didn't see any obvious failures.

    I was thinking somebody who has worked on this kind of cross-volume redirect mini-filter would have surely come across similar issue.
    If you happen to remember/come across discussion related with UWP apps here, please do share the link to that discussion.

    P.S.
    I can upload the ProcMon log files if interested in having a quick look.

    Thanks

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,142

    We did a filter similar to yours a few years ago and didn't have any problems with UWP. Our design was different though in that we cloned the existing volume and implemented the cross volume redirection using isolation instead of reparse (we've found lots of things over the years that just don't like it when their stuff is split across two volumes).

    Are you returning (or being returned) ANY errors during the launch? Also, is ProcMon running above or below your filter? You might see different results. Then again, ProcMon only shows what it shows, so the answer might not be there.

    -scott
    OSR

  • ntdeveloper31ntdeveloper31 Member Posts: 16

    @Scott_Noone_(OSR) said:
    We did a filter similar to yours a few years ago and didn't have any problems with UWP. Our design was different though in that we cloned the existing volume and implemented the cross volume redirection using isolation instead of reparse (we've found lots of things over the years that just don't like it when their stuff is split across two volumes).

    This straight away would have taken care of the UWP issue, since you pretty much already have WindowApps directory structure in-place along with their permissions etc. Whereas, as per my design, I'm creating those folders and fixing their permissions only when accessed (more along the lines of COW).

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,142

    If it really is that sensitive to permissions you'll presumably need to copy the security descriptor for each file/dir you COW to the T volume. Seems like something you'd need to do anyway in order to preserve the security semantics.

    Presumably the UWP app is writing to something (and thus triggering your COW) while starting. Have you tried comparing the security descriptors on the COW files with the real ones? Can you manually change the descriptors on the temporary files and then launch the app again to see if that's really the problem?

    -scott
    OSR

  • ntdeveloper31ntdeveloper31 Member Posts: 16

    If it really is that sensitive to permissions you'll presumably need to copy the security descriptor for each file/dir you COW to the T volume. Seems like something you'd need to do anyway in order to preserve the security semantics.

    I already do that. After putting in lot of hours of investigation I found that as soon as I COW resources for these apps residing at C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_10.1905.28.0_x64__8wekyb3d8bbwe\Assets for example the app crashes. Whereas if I exclude C:\Program Files\WindowsApps from my filtering process, then UWP apps such as Calculator, Photos etc. start working fine.

    The COW process for a file/dirs consists of:
    - Enumerating all the ADTs & copying their corresponding data on to a virtual drive (applicable only for files)
    - Querying and applying Security descriptors

    I realise that in this process I'm missing out on querying and applying the file/dir attributes. So the attributes of virtual file against real don't match up and this somehow triggers the crashing of application? To be honest, it seems unlikely to me but something I should be doing anyway so I'll give it a go.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA