Now Sandbox states “Windows Sandbox failed to start. Error 0x80070002. The system cannot find the file specified".
As I explained in the Xiret topic, Windows 10 does not do that test anymore, at all. It is always 9.9, even for the worst graphics cards. The value is bogus, thus Xiret hides it. Or, in other words: There is no result for that test to show and never will be, on Windows 10.
Yes, I forgot to tell I found that information but Microsoft said it would fix it in late June. What does it mean by saying the system language is changed during the update process, by the way? I have this problem after doing a clean install, so it isn't an update, and I also have it after doing an upgrade pt-pt version install or installing the pt-pt version via WU when I already had a pt-pt version installed.
Sorry, I assumed you missed that info regarding current .207 release. That situation is unexpected, hopefully it'll be solved soon. Maybe clean installing en-us and later adding a pt-pt display language for your user could solve it for you, but that's too much work for something that shouldn't be happening.
I did some testing on a VM (network fully disabled for the entire test, VirtualBox in EFI boot mode): created an UPP -> 18362.1 amd64 ISO without integrating any updates and did a regular install with default choices, added the DisableResetBase=0 registry key and ran /ResetBase (out of curiosity how it behaves on the fresh install). It unexpectedly took a few minutes. A second run completed instantly (as expected), rebooted, installed 5 (now superseded) updates manually from MSU packages (.NET, Flash, Intel-MC, SSU, CU .145), rebooted and checked that all 5 updates show up in the Control Panel / Programs and Features ran /ResetBase which took a few minutes (as expected, since there was some work to do) and now displayed two lines of progress indication lines (as usual, except for the run on the clean install state). Rebooted, installed the fresh versions of all the 5 MSU packages (with the CU being the last in line) with no errors, rebooted and checked the build number: .207 The only thing I forgot about was enabling .NET v3 right after the clean install (which I normally do or have the UPP->ISO converter do it when I integrate updates but it looks like that needs a .NET service pack present to work - which is strange because the installer should be available anyways [since it's in the final ISO] but I wouldn't expect the "service pack" to be a full installer... strange...). So, what's the real difference here? After I had so many issues with CU installs, I thought it was /ResetBase but now it works. Is it about the actual content of a specific CU (what files it patches)? (So /ResetBase does break CU installs, just not always...?) I used this registry key (in the VM for the test): [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Configuration] "DisableResetbase"=dword:00000000
Can you use Sandbox on Hyper-V? I can't even select it from the control panel (it states it doesn't suport virtualization) after installing the Windows 10 1903 18362.1 Enterprise pt-pt build (without doing any update install before [I didn't try using it after installing updates]). Maybe it's normal because it's being executed from a VM.
VMWare has an option to virtualize vt-x and amd-v to a guest, unfortunately I don't use hyper-v be able to help you.
That suprises me but its totally understandable considering how much logging and space hogging windows does. I went through a stage back when i was using a hdd for the os and i would put all my programs onto a usb key and i was amazed at how fast even Nero 8 would start up I am considering going back to that. I killed a Crucial BX500 120gb drive in a year, down to 18% health.
I couldn't agree more. He must be using SSD reliability information from the early days and discounting up to date information on the measurable improvements in NAND densities and reliability that have brought the cost to gigabyte ratio down to on par or exceeding levels to mechanical HDD's which are in fact more likely to fail due to moving parts.
I respect @TairikuOkami's opinion, as i do @bfoos and @MrMagic 's but the fact of the matter is i still killed an ssd within a year so @TairikuOkami does have a valid point.
Not really, I could kill a car in a year if I drove everywhere with my foot to the floor, or it could last 20 years if I looked after it HDD would fail long before with the same load And obviously with any hardware you get the odd thing that fails due to whatever reason, where the rest of the same line all work flawlessly for years SSDs are cheap and reliable and fast, no reason to say otherwise