The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
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 ?
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!||Kernel Debugging||30 Mar 2020||OSR Seminar Space|
|Developing Minifilters||15 Jun 2020||LIVE ONLINE|
|Writing WDF Drivers||22 June 2020||LIVE ONLINE|
|Internals & Software Drivers||28 Sept 2020||Dulles, VA|