Re: Nox Player Para Windows 7 32 Bits
Ashlie Hagenson
I've been having this problem for a while and can't seem to fix it so after trying with Microsoft Community with little result I decided to try here. Don't really know if it's the place for more user-side problems but I figured I'd give it a try.
Basically, certain applications, seemingly all system ones (at the moment Groove Music, now called "Media Player" on the Store, Movies and TV and Photos), simply can't update to their latest versions because of the error i cited in the title, which happens after a couple seconds of the Store trying to install the app, after completing its download.
The main problem is related to the Photo app though. It originally wouldn't update and would weirdly only display the english language, while the rest of the system is in italian, so I tried resetting it and finally uninstalling it by removing its two main components from Windows' Settings to see if it would yield any result on the Store side.
What I ended up doing is leaving my system with neither a way of rapidly opening and viewing pictures or reinstalling the Photos app, which behaves exactly the same as the other two with the exception i'm trying to get it on my system instead of just updating it.
I already tried resetting the Store's cache and updating it but it didn't work. The troubleshooter also didn't give results and trying to remove and reinstall the Photo's app package through Powershell didn't work too.
An interesting thing is that the Photos app exists and works on my secondary user account, kinda leading to the conclusion my main account is at fault here. I don't understand what could be going on though. Thanks in advance and sorry for the weird spacing but my keyboard is also facing problems lol.
3- The DISM tool will report whether the image is healthy, repairable, or non-repairable. If the image is repairable, you can use the /RestoreHealth (Dism /Online /Cleanup-Image /RestoreHealth) argument to repair the image.
Solution 2
It might be that something went wrong with the update files itself. Clearing the folder where all of the
update files are stored will force Windows Update to download fresh files.
Here how to clear update database cache, reset windows update components to the default setup.
100% fresh install of Windows 10, reinstalled 6 times trying to fix this issue after exhausting every possible solution I could find including the first 3 solutions you posted. The error code 0x80070005 is proving impossible to fix on a non Windows N locked version even after purging 100% of the store and downloads and making sure my computer is completely up to date. I even went as far as to try installing EVERY SINGLE THING in Windows Update to try and see if that possibly helped so I could start narrowing it down but still nothing at all. This issue has been making me extremely angry for weeks now because my Dolby Atmos "enabled" headset can't function without Dolby Atmos. If I try to use it then I get constant screeching from a failure to process non Dolby Atmos encoding. I have to say, I have tried absolutely everything at this point and am losing my mind.
I've understood the code stands for some kind of missing permission that denies the system access to components needed to finalize whathever process it's trying to perform, but it can be given out by Windows in a variety of situations and I guess solutions will look entirely different for similar cases even.
Mine had to do with the installation and updating of certain apps through the Microsoft Store. As I intially said, the system apps Photos, Media Player and Movies & TV would't update and remained in a constant error state in the Store's app view. The problem became worse when I experienced the exact same thing (error code 0x80070005 during the install phase) trying to get the new native Apple Music app and even the older iTunes one through the Store. The code unfortunately didn't give much information and I couldn't find a lot even in the once richer Event Viewer, which reported an installation problem happening but had pretty much the same depth as the message on the Store.
What I tried was trying to install the app directly from its .msix package downloaded from a pretty interesting website that appears to be fetching data straight from MS Store's servers. If you try opening such a package Windows will try to register it using an app installer separate from MS Store that actually gives some info on the error, which repeated with the same code but specified there was a problem with a certain "windows.fileTypeAssociation" extension and also referenced a precise point in the package's AppManifest, a document located inside it and viewable opening the .msix with a program like 7zip. I'm not an expert but there were references to this "fileTypeAssociation" function and a list of file extensions at the line and column specified in the error message.
The fundamental solution was going to the registry and then accessing the folder containing keys for basically any supported file format storing informations such as the programs that can open each, "HKEY_CURRENT_USER/SOFTWARE/Classes". I then selected every file format present in the problematic part of the AppManifest and found some of them actually had pretty fitting authorizations issues: existing keys couldn't be accessed or modified and new ones obviously couldn't be added, what was probably making the installation impossible. Changing the file extensions key security settings to "Complete Control" for the entity "Every App Package" miracolously had its effect and finally seemed to solve the issue. Trying the update or install process of the previously cited Apps from the Microsoft Store finally worked.
Don't know what exactly happened to the registry permissions and why but that's what I'm surely going to check first if anything like this happens again and what I can only suggest doing. Hope this can help and thanks for the numerous replies.
I already tried running an sfc scan a couple days ago and it didn't yield any particular result but I didn't know about DISM so I tried that one out as well but it unfortunately didn't fix the problem.
I really don't understand what could be going on here. The really weird thing is that as I said all of the apps i'm having problems with on my main account (which aren't the entirety of Microsoft Store apps by the way, just the three I cited for now) work and are perfectly downloadable and updatable on the secondary one, even the Photos app I can't even find in Windows Search on the other one. It seems it's the main profile's User folder that's interfering somehow even if my limited knowledge in the field of UWP apps and how they intgrate with the system and are managed between different users doesn't really let me to go any further at the moment. I just know most of the Store's app are placed in the WindowsApps folder which should be shared between all accounts so I don't get it.
I tried performing the fixes you suggested but they unfortunately didn't solve the issue, at least directly.
Running that last Powershell command did provide some additional informaton on the problem, even if I haven't really been able to make all that much use of it, hope you guys can help.
The registering process went fine for most of the packages except, probably not coincidentally, for the ones that the Microsoft Store can't install citing the usual error code. Looking at the log for the unsuccessful registration of the Photos app it gives the same "0x80070005" error code already seen in the store and says it's coming from the also unsuccesfull registration of a windows.fileTypeAssociation extension in the package's manifest (it also gives the precise location of the error in the text of the .xml file and it does coincide with an extension declaration) because of "denied access".
I've tried looking around a bit and all the manifest's doing is specifiying which file types the app is going to be suitable for, without making references to specific files or entities the system could have problems accessing. The only thing that comes to my mind is a problem with giving the app compatibility with the file types themselves, but I don't know.
Since it's quite essential to avoid adding any components related to .NET Framework for the sake of minimizing the size, I'm more interested in the command-line version (i.e. PlayPcm since it's written in C++) and found an older version here
PlayPcm.exe program size is currently 44544 bytes but if you strip functionalities such as DSF/DSDIFF decode and experimental unnecessary large page memory allocation code, 22000 23000 bytes EXE file is possible but I think it is waste of time, use sysinternals vmmap to measure actual program footprint, many DLLs (total 28MB) are loaded onto VM to run PlayPcm.
In that case, are you expecting both 705.6kHz and 768kHz files are compatible with PlayPcm console program by default? Basically WASAPI might have some issues with specific software players while others seemed to be OK so far
If getting 705.6kHz and 768kHz to work reliably were proven to be too much of a challenge, do you think that maybe ASIO could be an even better choice? I found that you should have conducted some experiments several years ago
No, it is large address aware feature of 32bit-windows app. default 32-bit windows app can use up to 2GB of user land VM, but specifying LARGEADDRESSAWARE flags to linker, app VM space is increased to 3.5GB. BUT there is a DLL loaded at 2GB and VM space is fragmented and contiguous memory space of > 2GB is not available even with the LARGEADDRESSAWARE flag. For further info, please read
d3342ee215