Talk:Windows 10 build 15035

NVIDIA Storage Controller

Does anyone know which was the last build of Windows 10 for ARMv7 that still had support for the NVIDIA storage controller? --Jwa4 (talk) 09:17, 29 May 2020 (UTC)

might be this one. I think 15035 is the only armv7 build of desktop windows 10. Correct me if i am wrong. BenjiMadden7850 (talk) 09:09, 29 May 2020 (UTC)

This one does not have support for it, with 15035 you have to use a version of the driver from Windows RT 8.1 but I'm wondering if any build of Windows 10 still retained support for it. --Jwa4 (talk) 09:17, 29 May 2020 (UTC)

not any that i know of. the rest of windows 10's arm builds are arm64. Sorry, i dont know much about arm stuff. BenjiMadden7850 (talk) 09:14, 29 May 2020 (UTC)

There are earlier and probably later builds for ARMv7 but its unlikely NVIDIA storage controller support would have been reintroduced at a later date. I suppose finding out at what point the support was actually dropped could be tricky though.--Jwa4 (talk) 09:24, 29 May 2020 (UTC)

true dat. BenjiMadden7850 (talk) 09:26, 29 May 2020 (UTC)

I was able to find some older drivers (sdbus and sdstor) in an IoT image of 10586, it does not appear that these support NVIDIA storage controller on Surface 2 either. At the very least they cause the same problems as the ones in 15035.--Jwa4 (talk) 18:08, 30 May 2020 (UTC)

Timebomb

Is the timebomb in this build ineffective because it is bugged or another reason?--Jwa4 (talk) 16:18, 2 June 2020 (UTC)

Inherited RT Limitations

Are the limitations inherited from Windows RT responsible for incoming Remote Desktop connections failing? I suspect they are but I don't know for sure.--Jwa4 (talk) 10:39, 30 June 2020 (UTC)

Bugs - MMC / PANIC_STACK_SWITCH

Do the bugs that result in PANIC_STACK_SWITCH happen on all devices or when running under emulation? Is it something that only happens because sdbus has been replaced with an old version on some devices?--Jwa4 (talk) 10:54, 30 June 2020 (UTC)

what are you running this build on exactly? BenjiMadden7850 (talk) 11:27, 30 June 2020 (UTC)

Surface 2. I was wondering if any of the bugs that show up are specific to Tegra hardware or caused by the driver substitution, if anyone has run it under QEMU or on Lumia they may be able to confirm. As far as I know these do not need the substitute sdbus driver.--Jwa4 (talk) 11:34, 30 June 2020 (UTC)

I've now been told the bugs happen even under QEMU where the driver substation is not required.--Jwa4 (talk) 15:47, 8 July 2020 (UTC)

maybe that's the reason they canned windows 10 client for arm32 some time after this build. BenjiMadden7850 (talk) 15:49, 8 July 2020 (UTC)

This bug happens with all MMC snap ins on any device. It isn't just exclusive to event viewer or disk management and can randomly happen. I am proposing to merge all of these bugs into a single one, mentioning that running MMC snap ins may create a bug check. Gus33000 (talk) 12:26, 9 July 2020 (UTC)

The bug seems to happen on demand with Event Viewer or Task Scheduler and rarely on Disk Management, interesting to know it can happen on all snap-ins though. Thanks!--Jwa4 (talk) 12:50, 9 July 2020 (UTC)

and what about the certificate bugs, what should be done about that? BenjiMadden7850 (talk) 12:27, 9 July 2020 (UTC)

Please see the section I added below Gus33000 (talk) 12:28, 9 July 2020 (UTC)

I have merged the MMC bugs into one.--Jwa4 (talk) 13:37, 9 July 2020 (UTC)

Certificate Validity

This build has to be run with Secure Boot disabled so why are certificates that are outside of their validity period an issue?--Jwa4 (talk) 15:40, 8 July 2020 (UTC)

No clue. Maybe you should ask on BA or xda developers about these observations in this build. BenjiMadden7850 (talk) 15:42, 8 July 2020 (UTC)

The user-mode certificate validation library is different to the kernel-mode one. 85.210.112.98 16:20, 8 July 2020 (UTC)

Are some of the bugs mentioned really relevant or even bugs?

I have noticed this article is getting quite a few updates about bugs. Considering this is a non production build, this is absolutely inevitable. However, most of the bugs mentioned are about signatures expiring. Why are we considering anything remotely linked to this a bug? You were never supposed to actually run the build past the expiration date, and things not working as a result is actually intended functionality. I should also add that the timebomb isn't broken. You see it as broken because you are booting using a firmware which has secure boot off (in reality it is not off on Surface RT, but your debug policy that is provisioned is acting as if it was made off), so the build boots fine because the UEFI does not enforce signature validation and certificate validity range checks. Gus33000 (talk) 12:25, 9 July 2020 (UTC)

Agreed. I will redo it.--Jwa4 (talk) 12:35, 9 July 2020 (UTC)

@Gus33000 - To clarify what I was thinking, some of the stuff added recently might be considered out of scope but I figured maybe this build might have some extra latitude giving how unique it seems to be.--Jwa4 (talk) 12:40, 9 July 2020 (UTC)

I understand your position well here, I'm also considering potential issues if one day x86 and amd64 counterparts leak to be honest. I think we could work out a section for the ARM compile specifically in case it happens, where you can put all ARMv7 related issues. And maybe we can also put the certificate issues into a section giving tips on how to use this past the expiration date? Gus33000 (talk) 12:42, 9 July 2020 (UTC)

Good idea, I will try to rework it.--Jwa4 (talk) 12:45, 9 July 2020 (UTC)

I have separated them out. Should the build ever leak for other architectures maybe this could be considered unique enough for an ARM specific page?--Jwa4 (talk) 13:50, 9 July 2020 (UTC)

I don't really see what is unique to this compared to the amd64 or x86 counterpart to justify a different page Gus33000 (talk) 13:51, 9 July 2020 (UTC)

Maybe. My outsiders opinion is that being the only publicly available Windows 10 client build for ARMv7 would make it a little more unique than others but I'm not active or knowledgeable enough about the beta community to really justify my opinion beyond that. Maybe this bridge can be crossed when we come to it should the build ever leak for other architectures?--Jwa4 (talk) 14:07, 9 July 2020 (UTC)

About the introduction of this article

Should we really write things like 'although it is known to have been in private circulation since early 2017'? This is the first page I have seen on this wiki mentioning something like this, and this wiki goal isn't really to document how leaks happen, and I doubt the site wants to go into that trouble as well, it adds little to not information, other than potentially reviving flame wars. Gus33000 (talk) 12:28, 9 July 2020 (UTC)

should i remove it? BenjiMadden7850 (talk) 12:29, 9 July 2020 (UTC)

nevermind BenjiMadden7850 (talk) 12:36, 9 July 2020 (UTC)

Gone, when I added that line I was going to add text about the way this build made its way into public hands but I could not find another page that had described anything in that detail so didn't do it.--Jwa4 (talk) 13:33, 9 July 2020 (UTC)

Well that piece of information is already in the article, it got leaked on BetaArchive first, then someone downloaded it from BetaArchive and reuploaded it to mega.nz in a telegram group. That's all about how it made its way to the public quite honestly. Anything between the day this got compiled from source and when it got uploaded is pure speculation, that you probably can't justify on an article due to a lack of facts. Gus33000 (talk) 13:42, 9 July 2020 (UTC)

gus33000,

Well, that's one way to say it. Another way is, it was actually being leaked somewhat publicly for years without your knowledge.

Another was it was actually being leaked somewhat publicly for years without your knowledge by Aljoshua Hell to anyone who knew enough to ask on the condition that the recipient did not tell you.

And even another way is, it was actually being leaked somewhat publicly for years without your knowledge by Aljoshua Hell to anyone who knew enough to ask on the condition that the recipient did not tell you becuase you leaked it to him and were afraid of some kind imagined fallout if it went fully public.

Beta Archive were the last to the party. The little daycare class created most of the garbage dramafest surrounding this build and and all it did was bring begging retards like moderate out of the woodwork... this is going off topic but the people who hoarded this build really threw gas on that douchbags yeast infection. — Preceding unsigned comment added by 193.148.18.104 (talk • contribs)

Very true, I know it caused problems for people but its still a fascinating bit of Windows history imho.--Jwa4 (talk) 13:53, 9 July 2020 (UTC)

Why is it a 'fascinating bit of Windows history'? Gus33000 (talk) 13:54, 9 July 2020 (UTC)

Probably more accurate to say its fascinating to me, I don't really pay attention to beta builds but while I have hardware capable of running it I find this one interesting. On a Surface 2 its actually pretty good - not a daily driver but not bad... quarantine boredom probably increased my interest too.--Jwa4 (talk) 14:00, 9 July 2020 (UTC)

Inaccessible boot device

When I set the dism to add driver in viostor, it got an error code 50, meaning it needs the latest version of DISM. I skipped that (like I shouldn't have) and followed the rest of the instructions. I got an error. Idk what to do there. Any help would be appreciated. --ClassicMacOSGuy1067 (talk) 22:14, 22 June 2023 (UTC)

You need a version of DISM from Windows 10 version 1703 or later. NaraInsider1694 (talk) 03:08, 23 June 2023 (UTC)