Migrating from Win10H on Surface 3

Hey guys. I'm a long time hard code integration programmer for some of the XP and Server 2003 based flavors of WinPE and dropped all of this after I was happy with Server 2008. My development machine is now a Phenom II X4 955@3.2GHz with 4GB DDR3-1600 running Windows Server 2012 Standard but I am struggling to tune a mobile device with it and it's a perpetual nightmare. Target device is a Microsoft Surface 3 with an Intel Atom x7-Z8700@1.6GHz and 4GB DDR3-1600. All I ever run on here is OneNote, Skype and Discord but rarely all at once.

Reason being, of all the computers in the house, this is the newest yet only device I've ever had problems where Windows will randomly freak out about running out of memory and shut down programs for eating past the memory commit limit. The webcam seems okay for one on one but when there's multiple people in video chat, the device will bog down until it completely locks up, forcing me to hold power and do a hard restart. Also, this is the third random day out of this year where the Marvell wireless adapter driver randomly shat itself forcing me to run around looking for the problem this morning for two hours right before I needed to get out the door. This is also the only device I've ever used where there's well over 100 background processes running around in the task manager. It's running 3x the processes of my development computer at half the clock speed. This is running like frustrating garbage and I need to do something about it before this becomes my bane when in the middle of something and this becomes a mission critical mobile device. I'm convinced at least 80% of these problems are related to Win10 itself if not the factory install or silent upgrade and I'm unsure how to proceed with a refresh. I can theoretically reinstall Win10 or roll back to Win8.1 seeing how that is effectively the same OS running on my development computer but in practice, it isn't possible.

I need to create a UEFI flavor of WinPE that not only starts up to allow maintenance or reinstallation but it needs to load network and touchscreen drivers at startup as well and that's where I'm completely lost. Where do I start to make this happen? Windows Embedded 2013 hasn't been much help for a temporary environment and I'm not even sure how to get things working when this all has to load from the one and only full size USB port on the tablet.

Run Windows 10, open the device manager, change view per connection.
Are keyboard and mouse childs from GPIO or I2C controller?

Build a Win10PESE.
Open the Driver Integration plugin. Add GPIO and I2C drivers to %GlobalTemplates%\Drivers_x64\

Inlclude the network driver the same way.

https://www.microsoft.com/surface/en-us/support/install-update-activate/download-drivers-and-firmware-for-surface?os=windows-10
http://www.microsoft.com/en-us/download/details.aspx?id=49040
Surface3_WiFi_Win10_161250_0.zip

Did you tried USB hub connected to the USB port?

GPIO Buttons Driver
GPIO Laptop or Slate Indicator Driver
I2C HID Device
Sideband GPIO Buttons Injection Device
Surface Digitizer Integration
Surface Pen Settings
Surface TouchScreen Device
HID Keyboard Device
HID-compliant mouse

I don't have the hardware to setup a USB hub and even though that's probably the real solution, I really want to make this happen without one.
So my starting point should be a Win10PESE? I understand the target is a 64bit OS and the drivers are issued specifically to that arch. Am I stuck with 64bit?!

It's a 64 bit UEFI implemenataion. Yes, use 64 bit OS and drivers.
Neither Windows 8 or Winows 10 incluedes GPIO and I2C drivers by default, Hence add them yourself.
You may try both Win 8.1PESE or Win10PESE. I don't know details out of memory, onscreen keyboard is a OS function and may be supported.
After boot, you may disconnect the PE media and connect another USB device.

Yeah I've noticed that I've been having really good luck with a custom Win 8.1 PE that loads entirely into memory and then I can disconnect the drive and add a wireless USB mouse. I guess the real issue is getting either the touchscreen driver OR the network driver but having both would be an immense luxury. Still not sure if I should continue on Win10. This is some frustrating trash and nearly impossible to navigate. I just need to make this a production machine.

The file Surface3_WiFi_Win10_161250_0.zip contains a lot of drivers. There is a Win8 file available too.
I suggest to add the drivers step by step, as less as possible.

Drivers\System\GPIO
Drivers\System\I2C
Drivers\Display\SurfaceTouchScreenDriver
Drivers\Network\WiFi

View device manager details.
Which .inf and .sys files goes to the Surface TouchScreen Device?
Are this Windows default files or addional files?

I've opened a small testlog to keep track of everything going on to ensure I get what's necessary before figuring out what I need to choose for a PE base. So far it appears that I can get each test build to boot on my server from chipdisk, but the real test is getting each build to run on the Surface. At some point I managed to get a crap x86 build of Win7PE to start but it's too limited to be of any use. The Surface is new enough and Win8 is old enough that there are no drivers available for this device through Microsoft and when I back them up and try adding them via DISM, the integration fails. This morning I found the super helpful SDI-Tool and found numerous updates for my 2012 server and Win10 Surface. Most of my antique hardware doesn't typically see updates but the cutoff for the Surface 3 seems to be specifically between the x64 builds of Windows 8.1 and Windows 10. The only helpful and stable UEFI compatible WinPE builds for this device are going to be related to these specific operating systems. This is where things get interesting, and very much broken with each build.

The WinPE needed has a very short but incredibly difficult list of requirements to make this work. Mind you, all I'm trying to do is make an appropriate preinstall environment that WORKS on this device that wipes the disk, copies Windows setup from a network share and launches setup. Due to the nature of this hardware it needs to run entirely in RAM(hotswap with a wireless mouse) OR automatically load the touchscreen driver(which I manually load after WinPE starts but can't integrate it into startup?). Both require use of the onscreen keyboard. It needs to load the Marvel WLAN driver, which doesn't seem to be possible at the moment, connect to the network share and run setup. I'm fine with partial Explorer or Double Commander as the shell but the inability to load the OSK, WLAN drivers or map a network drive is confusing. This should never be so difficult when trying to do something this specific with such a broad set of options available. This is leading me to a new issue: I'm getting better results from building Win8.1SE PE with the 2013 CEI release and even the Windows 8 x86 CDP than using the more common Win8.1 and Server 2012 x64 customer builds.

MistyPE is flat out terrible with UEFI but works great on older BIOS based desktops.

EZPE5 is completely one sided depending on the build sources and limited due to some script nature that doesn't allow me to build from Win8.1 install media and needs patching with files from EZPE3. If I use the Windows CDP I get a failure on the Surface but get interesting behaviors on the desktop like a stale Explorer and immediate link to the network share at Wpeinit despite getting a "No adapters" report under PENetcfg and PENetwork. The Windows CEI build runs on both systems, gets partial Explorer but is restricted to LAN adapters, no WLAN and the OSK refuses to run, making it great on the desktop but once again an impossible pain on the Surface.

Win7PESE with Win7SP1 runs on the desktop and hangs on the Surface but gets FULL Explorer, full LAN and partial WLAN under PENetwork but is incapable without the OSK since I have to login to everything manually and can't copy/paste anything.

Win8.1PESE outright fails under a Win8.1 x64 source with an error screen similar to WinRE minus the WinRE components. No idea why. The Windows CEI build runs fine on the desktop and I'm getting ready to test it on the tablet. If it goes okay it would be nice to have the OSK working because getting it to work has been a nightmare.

I think a Win10PE is the best for your needs.

touch screen, WIFI will easily add with WinRe.wim.
or ADK maked winpe.wim.

alternate OSK with FreeVK
http://freevirtualkeyboard.com/virtualkeyboard.html

alternate explorer with WinXShell
http://theoven.org/index.php?topic=2090.0
(add some *.dll , you can use a FileDialog as a File Explorer for copy/paste anything, you can also access LAN network share files as usual.)

use PENetwork for the network stuff.

Sure seems like it. I had the Recovery kit and ADK at some point and don't remember where WinRE came from but the quick boot copy ran fine. It DID load the touchscreen driver and I believe it had a tabtip keyboard, which is more than I can say for each WinPESE. Even my Win10PESE was a mess that required I manually load numerous GPIO drivers and then get touchscreen functionality. Works with the pen too. So for what I'm doing, WinRE already has 95% of the workload done by default. The only snag is network support and I never bothered to try net use \\server\Win in WinRE when I had the chance. I'm guessing it fails but would work after net start or PENetwork loads.

With a varied selection of media, I'm ultimately stuck between a hard choice of wiping everything to try Windows 8.1/CEI or giving up and reinstalling Windows 10. Should Windows 10 be my trusted build media for both scenarios or are they dependent on their PE version? It seems innocuous but I've noticed between Windows 7/8.1/10 these become temperamental even between the most vanilla builds. Each WinPESE solution is specific enough that I can't be bothered by all the completely different arrangements and would like to make a 8.1/CEI based WinPE behave like my Win7PESE solution but so far the Surface UEFI isn't having any of it and WinBuilder doesn't work with exotic build numbers.

I'm not too worried about shell or other internal app support but the OSK issue is bad enough that I'll look at FreeVK. Any independent virtual keyboard that functions the same across each OS sounds like a win win to me.

FreeVK plugin already available, See :
\Downloads\AppYGS\Accessibility\FreeVK

an OSK plugin also available here:
\Downloads\ComponentsY\Core\1 System\Accessibility\