System Requirements for Windows 10 Pro 64-Bit Build 16237.1001?

:START

:BEEN HERE BEFORE goto END

Colin hits the bulls eye!!

**George continues to predict a major Fall Fail for Windows 10**- **Unless Microsoft (at the very least) permits signed 32 bit drivers!**

Users running 32 bit applications may also suffer with 32 bit apps rendered useless or forced into updating to 64 bit apps (if possible) and without additional software licence costs. OK I'm a Scot but I'm by no means mean.... I just appreciate good value!  Many may opt to downgrade to 32 bit Windows 10 but that involves the hassle of a clean install and total rebuild of the environment.

UPDATE 2

64bit Install of Windows 10 of builds after 16199....... I'll keep this as short as possible I promise....

As mentioned earlier, I was able to update to the 64 bit build 16199 without a problem.

OK, sometimes with the odd hiccup but nothing terminal and a clean install of 16193.1001 completes successfully.

Subsequent builds, (16215,16226, 16232. 16237 and 16241) either as one of 563* updates or 684* clean installs, have ALL failed. (* estimates provided by my wife Claire)

It rather looked like Microsoft had missed migrating these drivers but the Nvidia drivers appear to be in the C:$WINDOWS.~BT\NewOS\System32\drivers and in C:$WINDOWS.~BT\NewOS\System32\DriverStore\FileRepository. The same location where the 32 bit drivers reside in the build from which I was updating - but may be missing from the ISO of the build - I've still to look into that.

Perhaps the withdrawn build 16212 has something to do with this? OR perhaps Microsoft is intentionally forcing users to completely migrate to 64 bit drivers and applications. Now I'm all in favour of improving the security of Windows... the good Lord knows only too well that it's needed! HOWEVER...

• Is this the right time?
• Should it be done without warning the average Windows user who's running a 64 bit OS, 32 bit drivers & apps?

I think not!

I'm guessing its a good old fashioned cock up and that something changed with WOW64 and/or the permissions regarding signed 32bit drivers. I sincerely hope so and that a fix is being worked or, like my updates or clean installs  :RETURN to START

:END

Your thoughts welcomed.

P.S. Currently updating from 16193.1001 to 16241.1001 for the 564th and FINAL time!!

Update 1

install of 32bit 16232.1000....  for the 3rd time!

(Before getting into the details, I forgot to mention the error on the second attempt..... according to technet's list of errors, error 0x80242015 is described as - WU_E_UH_POSTREBOOTRESULTUNKNOWN - The result of the post-reboot operation for the update could not be determined.)

Anyway, I followed exactly the same procedure as before, the same USB, the same bare IDE drive and another clean install of 16232.1000 was achieved with the same updates as above on the Slow ring.

So far so good...

update to 16421.1001.. for the 3rd time.

Switching to Fast ring the update was downloaded and it appeared to work perfectly all the way through the preparation phase to the restart and install phase with interim restarts as around 30% and 70%.

Finally it has arrived.... great news.... well almost... .after the final restart a few minutes later my first ever GSOD!!

It eventually restarted and, fingers crossed, no more issues will arise.  I've searched the error but nothing much I could find helps identify the precise cause.

Anyway, the drivers appear to have migrated this time although they are unchanged....

So despite two failures, using exactly the same approach, it eventually worked.... but hardly consistent and will cause many to curse Windows 10 updates. I'd continue to test the functionality of the build but I need move on.

So it's now back to the 64bit install and updates but, having been there many more times than with 32bit, I'm not holding out much hope.

Cheers

G'day Chaps,

Well, just like an itch you can't scratch, I did some more testing last night - totally against my Mum's advice of "Don't pick it or it'll never get better!" – but I had to stop at around 2am when my wife awoke to not find me!

This is longer than I’d like but, it will give you a deeper understand of the problem and why I’ve been crying out about a potential disaster when the Fall update is let loose……. I believe you’ll find it’s worth your time reading this as much as the effort I put in to writing it…..  

OK, it rather looks like I'm getting closer to identifying the problem and will, as Stephen suggests, document the driver details as I progress over the next cycle of tests AND there's probably some merit in Colin’s theory on the driver signing angle

• 32bit vs 64bit - although, so far, is seems they’re all signed by Microsoft.

HOWEVER, based on my latest tests, and given Jason's latest description of the "The new (update) process" “Drivers and other required OS files are migrated” confirms my thoughts on why I got to build 16199 before problems arose. This description can be found on the Feedback Hub 18^th^ July and is why I believe UUP is also a contributing factor. If you know Jason, please ask him to read this… it would also be nice to read a post from Jason telling me that I should either give up on my Insider testing as this PC set up is being “retired” or informing us all that Microsoft is aware of the problem, is investigating and plans to come up with a fix - nor not and that there will be a graceful way of terminating the update process. For the sake of Windows 10’s future I sincerely hope it’s a fix before the Fall update!!

Anyway, here goes…. successes and failures with 32 and 64 bit installs and updates starting with build 16232.1000 - although from previous tests the problem appears to date back to 15063.0 when the 64bit drivers either disappeared or were rendered useless. As I’ve said before, the 64bit 14393.51 installs OK and updates worked all the way through to 16199 – thereafter all updates have failed.

BUT before that, just to set the scene, clarify the environment and avoid repeating myself which I hate doing and, I’m sure, you hate reading just as much……..

• Hardware – a self-build, with an Asus P5N32-E SLI Plus (with a motherboard chipset that relies on Nvidia’s nForce 750i SLI drivers), an Intel Core2 Duo E8600 CPU, 6M Cache, 3.33 GHz, 1333 MHz FSB,  8Gb DDR2, 1xIDE (120Gb), 2xSATA (200Gb – a pair no RAID), a Plextor PX-740A CD/DVD dual layer burner, a 2016 generation Nvidia GT710 graphics card, no “floppy” drive – oh how I miss it ;) – a rather nice Cooler Master case with a juicy 750 watt PSU. (Have I missed anything relevant?)
• Peripherals – a Microsoft Internet Keyboard Pro (connected by PS/2), a Microsoft IntelliMouse (optical connected by a separate USB port)
• Software – nothing other than what the powers that be (Microsoft) included in the OS build.
• Having run out of DVD's to burn I've opted to install using RUFUS (Version 2.15 Build 1117) .... OK I know... I should have done that some time ago but I'm a traditionalist. A DVD only needs to be written once but takes longer to produce while RUFUS is much faster but would require a dozen or so 8Gb USB drives.
• ALL USBs were on a Sandisc Ultra Fit 128Gb and created using the latest Insider 16232.1000 builds of the 32bit and 64bit ISOs as downloaded from the Insider preview page.
• ALL installs attempted were performed on an unformatted drive – the 120Gb IDE drive.

32bit Install & Update

16232.1000 booted and installed successfully, with Slow ring updates..

On switching from the Slow to Fast ring and checking for updates saw 16241.1001 downloaded,

carried on through the preparing to update phase

but on “Restart” it did just that and only that. No installing updates on the restarting screen prior to shutting down and no sign of an update on the restart. The first update attempt shows the “Update History” telling me that it was “Successful” (?) while “winver” shows the installed build as 16232.1000.

A second attempt, after another re-install failed.

Why the inconsistency who knows but a third attempt is progressing as I write.... if I get a different result more later.

Conclusion – It appears likely that the 32bit chipset drivers are included in the 16232.1000 build but were NOT migrated during the update process to 16241.1001 hence, on restarting, no update was performed and the reversion to build 16232.1000.

Driver Details (only storage devices as the LAN and Graphics will only become an issue after the OS is installed)

64bit install & updates

16232.1000 partly booted getting as far as the Windows 10 logo but that was it, timed out and rebooted – repeat until when you get bored. Clearly no attempt to update to 16241.1001 was possible.

Conclusion – It appears that the 64bit chipset drivers are NOT included in the 16232.1000 build (and from previous tests not since 15063.0)

Driver Details – nothing to be said other than they’re missing. However, I can install 14393.51 and update to 15063.483 so I’ll update below with details of the drivers when I get there.

That's it so far.... 

Cheers

Colin, I would not be surprised at all, if you did not hit the bulls eye here, smack bang in the middle /--)

So much so that I have adopted this as my primary working hypothesis. I will do some research on what's involved in (driver) signing in general and let you know if I find something interesting. But I have one question for you NForce750i owners which I can't look up. Could please look at your various installs and post the driver info? If you could post build, architecture, publisher, version , date that would be most helpful. Thanks already.

I wouldn't write it off so quickly.  Remember that 32bit device drivers do not require driver signing but 64bit ones do.  It may be no more that a driver signing glitch relating to NVidia drivers of that period that may eventually get straightened out.  At least that is one thing that could cause 32bit to install but 64bit to fail.