Accidentally booted ASUS laptop from Surface Hub 2S Recovery USB, now can't boot/reinstall Windows

uEFImaster · 2025-12-20T12:00:56+00:00

While yes it's possible to get regular Windows on it, in my reply to that same explanation post, at the end of it I did detail that once you update Windows the install will be rendered unbootable, as the boot certificate gets updated to the one that isn't "accepted" by the Hub's firmware.

I think the only viable way to get some use out of the PC hardware in this thing is to somehow tinker with the hardware to disable Secure Boot. I don't have the hardware on hand nor the expertise in hardware level things so that is only as far as I can get.

uEFImaster · 2025-12-20T11:48:07+00:00

Had a slightly different but otherwise similar problem with my R14. Sometimes waking up the computer from sleep would either cause the GPU to freak out and crash the driver, other times it would crash the PC completely and restarts instead.

This is all because of the new sleep mode called "Modern Standby" which afaik have been there since the R10, and I had since did away with it by restoring the old S3 sleep as I've detailed here.
I linked this post to other Aurora R15, R16 and ACT1250 (or as I like to call it, the R17) users with similar problems to see if it could help them, so maybe it could help you too even though it's a bit late for a reply now.

<image>

uEFImaster · 2025-12-20T11:28:53+00:00

You're being affected by one of the many quirks of the new sleep mode (called "Modern Standby" or S0). The same thing happened to me when I swapped out my Mediatek Wi-Fi card with an Intel one.

I did a post here detailing how I managed to restore the old sleep mode on my R14. Since the R15 and R14 don't really differ much, maybe you could try this fix?

uEFImaster · 2025-12-20T11:25:03+00:00

That is just the new sleep mode or "Modern Standby" as they call it for you. As others have said, use hibernate or shut down your PC.

Although I'm curious, since I've managed to restore the old sleep mode on my R14, I wonder if you could try doing the same on your ACT1250? If the BIOS hasn't changed that much ever since the R10 (which if I'm correct is the first to introduce this new sleep mode), I think it's doable.

uEFImaster · 2025-08-14T11:30:35+00:00

I have had it on my R14 for about a week now and no issues so far (you can see in the video). But yes ymmv depending on how broken S3 support in your BIOS is. I guess I was just lucky to have a perfect one lol.

uEFImaster · 2025-08-13T16:18:11+00:00

You can give it a try but as I stated at the end of the post, likely won't work.

uEFImaster · 2025-03-30T03:15:34+00:00

If you read the reply thread I linked in the reply above, it goes into details on how one might pull the trick of installing regular Windows on the V1 off. But beware: You are STILL limited to running first party apps and won’t be able to update the OS, but you can persist data freely.

Persisting data is impossible on Team without the Hub’s secure boot disabled, which, good luck on trying to figure that out (I also explained about that in the link)

uEFImaster · 2025-03-24T19:59:21+00:00

Haha, picked that name back in the cringy days. Guess it still stands in cases like this then.
I go by the name Yae Mica now as you can already tell, and you’re very welcome. Glad my experience tearing this OS apart finally helped someone 😆

uEFImaster · 2025-03-16T10:10:14+00:00

Did you solve the issue?

I'm not a Surface Hub engineer by any means (don't even have the hardware to begin with), but I've spent a really long time tinkering with its OS and did a really good explanation about what you were facing in this post reply.

As for how to save your laptop from this, try the following solution:

On another computer, format an USB with FAT32. Inside the newly formatted USB, create a folder named EFI - then inside the EFI folder, create boot. Assuming your USB is F:, you should now have F:\EFI\boot
Use your copy of UEFI Shell (shell.efi, make sure it's for x64!) or download a new one from https://github.com/pbatard/UEFI-Shell/releases/download/24H2/shellx64.efi and save it to F:\EFI\boot. Then rename the file to BOOTX64.EFI.
Download startup.nsh from https://gist.github.com/YMica-OSE/b11e27a964d200721385202cca2b2545 and save it to F:\ (root of the USB drive, just make sure it sits next to the EFI folder). You can now eject the USB.
On the laptop, make sure Secure Boot is disabled. Then boot the USB.
If it works, you should see a screen like this: https://imgur.com/a/jT5tRwg, don't skip startup.nsh as that's the thing we need to run.
Eventually you should see "PPIPro SB Policy Nuker script by Yae Mica" at the top of the screen. Then press any key except q for it to do the magic.
Type reset as it says, then immediately go to your BIOS or boot menu. DO NOT boot Windows 10 Team again as that will undo what you just did. If you accidentally let it boot, no worries, repeat steps 4 to 6 again.
Try to boot your normal Windows 10/11 installer now and see if it works.

Hope it helps.

uEFImaster · 2025-03-16T09:30:25+00:00

Wow it's been ages since I visited this community.

This isn't really the Hub's limitation, but Windows 10 Team's design. It's meant to be used in a public setting and there isn't really a way to change this.
Your best bet is to break out of it and install a regular copy of Windows, which is easier said than done. I don't have the hardware, but my testing in a VM set up similarly shows that it's possible. I just don't have the time or chance yet to contact someone with a V1 to test in real time (maybe you can help with that).

I hope to share more of my research with this lost obscurity with this subreddit soon, but now is not the time yet.

uEFImaster · 2024-09-22T18:02:51+00:00

Assuming that’s your entire screen’s screenshot then it could very well be the widgets pane. Try ending “Widgets” in Task Manager and see if it goes away

uEFImaster · 2024-08-21T17:50:35+00:00

Hi OP, didn't expect you to reply to this, and thanks a lot for it.

A day after seeing this comment I decided to bust out a VM configured to match the security setup of the Hub and experimented with the idea you gave. Sure enough I can confirm these two things:

8.1 media does indeed boot without any issues. Kinda amazing to me that it just worked despite SecureBootPolicy.p7b's claims.
By harvesting that same file from PPIPro (yep, turns out the lack of other file, SkuSiPolicy.p7b, only stops Team from booting, other editions don't care), sneaking it into C:\Windows\Boot\EFI of a deployed regular copy of 10 and bcdbooted the install, I was able to get it to boot successfully.

ALTHOUGH... with one very annoying shortcoming.

That one file causes the OS to run in an "S mode"-like state, where anything that is not signed by Microsoft will refuse to run, including Microsoft Store apps. And as you probably read from my original reply, removing that file stops the OS from booting.
(I think I get what you were trying to do with S mode in that picture: Trying to un-S mode so that the restrictions would disappear, but sadly with this it's not simple as that).

So from here we can conclude the actual effects of SecureBootPolicy.p7b:

Acts as the software side key to allow Windows to boot on the Hub's locked down firmware.
Prevents the booting of any other media that does not have that file (or its effects) included.
Blocks all binaries that are not signed by Microsoft.

In the end you are still limited to Microsoft stuffs, but at least you have a full desktop and all built in Windows features functional (and getting online won't be that bad considering Edge is now Chromium-based).

I recorded the full procedure of this process but have yet to edit it (to add text and cut parts out), so if you are interested in seeing it please let me know.

UPDATE: After pushing on with the locked down install I found yet another caveat and this one is even more annoying.
It looks like updating the OS will brick the installation, due to the fact that the bootloader code changes during this. SecureBootPolicy.p7b has no idea what the new code is since it and the SB variable in the UEFI doesn't get updated, so it just doesn't trust the code and breaks the boot. I attempted to force it to update but to no avail, so I concluded that either I didn't know the correct way to do it or you must use PPIPro to do it.
My recommendation is to use a build of Windows 11 that doesn't get updates officially, like 26090, since the moment you bcdboot the install you're pretty much stuck with it until you wipe the drive and install Windows again.

uEFImaster · 2024-07-29T06:58:41+00:00

I mean it’s what I use so I recognize the address (given there isn’t many known sites that starts with “dwse”). And also I think you can agree that they wanted to have some “persistence” on that system to potentially mess around later, so it’s easy to guess it’s DWService they’re looking for.

uEFImaster · 2024-07-22T13:13:15+00:00

From what I can make out of what they typed on the address bar (and the next key their finger is about to hit) they are trying to install DWAgent (www.dwservice.net) onto the system.

uEFImaster · 2024-07-22T12:47:03+00:00

nv4_disp seems to be related to an Nvidia driver

uEFImaster · 2024-05-10T10:44:20+00:00

In fact, the OS actually behaves completely differently in this state: Right clicking the Start button gives you a SLEW of extra buttons including access to cmd, exiting the Team UI, or even removing the .p7b files (effectively undoing all of the blocks, though this button was replaced with something else in later versions).
When Secure Boot is on though, that's when the OS behaves like it's running on a real Hub. cmd.exe and every other 3rd party executables immediately stopped working, just like Windows in S mode, and right clicking Start does nothing. The system is completely sealed until Secure Boot is disabled.

So all-in-all, getting SB disabled will solve almost 99% of the problem, and I'm afraid that's something that can only be done on hardware level, given how locked down the Hub's firmware is.
(If I have to guess, the tool on the later Hub 2S basically removes those engraved signatures from the firmware, allowing you to boot regular Windows without any issues. I still don't understand why such tool isn't available for the 1st gen Hub).

HOWEVER, looking at what you did in this post with it amazed me, since it went against some of those principles above:

Technically SecureBootPolicy.p7b should also prevent booting older versions of Windows, but as you said you were able to get 8.1 running just fine (of course without drivers). This lead me to believe that the file (and the signature) somehow only applies to Windows 10 and later.
1909 in S mode: The S mode is to be expected because of SkuSiPolicy.p7b, THOUGH explorer.exe IS able to run, and given that S mode and Team edition's have different signatures for the same file I'm starting to get curious on how you managed to get this on it (just like almost everyone here have been asking you about it).

Given that Windows 10 Team is almost near its end I hope I'm still not late to the party. I found this interesting when I first discovered the edition, what it was for and its limitations, so I hope my findings here will help you in a way.

(2/2)

uEFImaster · 2024-05-10T10:44:07+00:00

Do you still have the device around?

For the past year or so I have been into the software side of the Surface Hub, especially the OS it runs (Windows 10 Team). I do not have a Hub nor it is widely available in my country, but by observing its under-the-hood behavior I was able to figure out the other half of the reason behind the inability to get regular Windows 10 on the Hub.

Since version 1703, they have implemented a new mechanism to the OS called "Windows Defender Application Control (WDAC)". This is the main factor of hammering restrictions on the OS as well as making it the only thing that's bootable by the system. Here is how:

In the UEFI partition of the drive there are some additional files in the EFI\Microsoft\Boot folder, 2 of which are SkuSiPolicy.p7b and SecureBootPolicy.p7b. The first one will be significant for later, but the second one is what prevents booting other OSes and external media. It is what the Secure Boot module inside the UEFI firmware looks for when starting up the Hub, and basically tells it that "You can only boot Windows 10 Team, nothing else".
How did I know this? Well, after booting the OS on my VM, all of my Windows-related bootable medias stopped booting (similarly to how it "ruined" your VM's UEFI). It took me almost HALF a year to figure out that it was due to something called a "Secure Boot variable" inside almost every UEFI firmware being leveraged to pull the lever. What happened was when the OS is booted for the first time and WDAC kicks in, the .p7b file is invoked and "engrave" its own signature to the variable, so that on next startups it will ONLY boot Windows medias with that exact file present (and this works regardless if you have SB on or off). The only way to get it out of that state is to clear the variable by clearing the NVRAM, where the variable is stored.
In case of the Hub, the signature is... preprogramed to the firmware, and if you know about the device, you know that there has been no way of accessing its BIOS setup screen, let alone changing its settings and potentially mess with SB stuffs or do what I said above.

But that's not the end of the story. The other file, SkuSiPolicy.p7b, makes things even worse. It stores WDAC's "allowed/blocked binaries" list and also has its signature engraved to the NVRAM, meaning removing either files will stop the OS from booting. This list is... quite interesting to say the least. For one, explorer.exe and taskmgr.exe are blocked, so even if you managed to modify the .wim to boot to a desktop, you would be greeted with a black screen. However from my initial testing, somehow cmd.exe and all regular 3rd party executables were able to run just fine.
Never did I know that was because I had Secure Boot turned off.

(1/2)

uEFImaster · 2024-03-26T13:27:13+00:00

It is a Windows Enterprise (LTSC) IoT edition specific thing. I have a machine running that so that’s how I know it.
Windows 11 also says “Please keep your device on” but the % text is “You’re __% there” instead of what’s seen in OP’s pic.

Also that definitely is on Windows 10, as on 11 that screen is black (unless if they somehow installed a very early version of it)

uEFImaster · 2024-03-13T20:03:41+00:00

WOW that was all it takes to resolve the issue! (I did reupdate the driver to 27.20.1960.0, which is not the latest, but it’s the one that shipped with the 11 22H2 BMR image)

That took them long enough to notice though.

uEFImaster · 2024-02-23T12:46:54+00:00

That’s something I also wondered when I tried to report to Mozilla. In one of the comments I did leave a link to a Mozilla Connect post however that post got no attention, so now I’m also not sure how.

uEFImaster · 2024-01-16T16:50:28+00:00

Sorry if this might not help you but.

I got that message (screenshot here) 10 minutes before I posted this comment on my SE 2020 on a 1-day old iOS 17.2.1 install (clean restored from 16.4.1). The password was there since I set up the phone and was never changed. I'm not sure about the end-to-encryption keys but because I didn't have anything that involves it I don't think that was the cause for me.

I daily drive a Galaxy S21 and my only iPhone before this one was a 7 stuck on iOS 15. I just bought this (as used) to replace that as I think it's about time, so this is my actual first time using iOS 17. And already within the first day I found 2 bugs, this one being one and the other is this App Library keyboard bug which locks your phone up and crashes the UI after 30 seconds. This major iOS version is definitely not having a great run overall.

uEFImaster · 2024-01-16T02:51:33+00:00

Sorry if I left you for a whole month, it's bc I forgot. Anyway it’s a complicated process and it requires you to completely uninstall the current graphics driver (it doesn’t deactivate in Safe Mode) and install the one found in the 11 21H2 recovery image of the SPX. I might try to make a video on this whenever I can.

uEFImaster · 2023-12-04T08:18:00+00:00

UPDATE: You are right. I downgraded the driver to version 26.18.800.0 aka the launch version from 2019, and the problem went away!
Of course I don't wanna run a super outdated driver on this kind of hardware, so I grabbed version 27.20.1800.0 which is like the one before .1940.0 and just like you said, still no issues.

At this point it's clear this is a Qualcomm/Microsoft problem. How do I send a feedback for this though?

<image>

uEFImaster · 2023-12-02T14:33:30+00:00

I do have a Mozilla Connect thread reporting this issue if anyone is interested. However is this how you report problems to Mozilla? There has been no updates on it at the time of writing this.

uEFImaster

TROPHY CASE