Microsoft recently launched its "Full Screen Experience" alongside the Asus ROG Xbox Ally and Ally X, packing what essentially amounts to a wrapper around the Xbox application in order to make the user interface more accomodating to gaming handheld form factors. It's a pretty big UI overhaul, but Microsoft also claims that it "improves system performance while gaming, battery life, and reduces the startup time of your device." This got me thinking: what did Microsoft actually do to achieve those gains? Where do they come from?

In our testing, we found that performance barely improved (if it did at all) when using the Full Screen Experience mode on the ROG Xbox Ally X, and that appears to be a fairly universal experience from what I've seen of other device reviewers. As it turns out, though, Microsoft does disable some stuff when booting into Full Screen Experience mode, and it's no surprise that performance doesn't improve by that much.

The boot-up process yields vital clues

It's mostly enterprise networking

I tested this using the Ayaneo 3, first updating to Windows 11 25H2 before switching on the Full Screen Experience feature using ViVeTool. I didn't enable it yet, though: instead, I went to msconfig and enabled "Boot log," under the boot tab. This logs the entire boot process to %WINDIR% (typically C:\Windows), to a file called ntbtlog.txt. This contains a list of every driver that's launched as a part of the boot-up process.

As I didn't know whether the updated Xbox application would bring in any additional drivers or changes, I elected to enable the feature selection and get it to a state where I can just flip the toggle before opting to log the boot process. This way, I reduce the differences between the two. I booted it up normally and saved the log file externally. I then enabled Full Screen Experience, booted it up to the Full Screen Experience UI, then saved the same boot log file externally, too.

Comparing the two boot logs using a diff tool, I noticed these log entries in the boot-up process when Full Screen Experience was disabled:

  • BOOTLOG_LOADED \SystemRoot\System32\drivers\rassstp.sys
  • BOOTLOG_LOADED \SystemRoot\System32\DRIVERS\NDProxy.sys
  • BOOTLOG_LOADED \SystemRoot\System32\drivers\AgileVpn.sys
  • BOOTLOG_NOT_LOADED \SystemRoot\System32\DRIVERS\NDProxy.sys
  • BOOTLOG_LOADED \SystemRoot\System32\drivers\rasl2tp.sys
  • BOOTLOG_NOT_LOADED \SystemRoot\System32\DRIVERS\NDProxy.sys
  • BOOTLOG_LOADED \SystemRoot\System32\drivers\raspptp.sys
  • BOOTLOG_NOT_LOADED \SystemRoot\System32\DRIVERS\NDProxy.sys
  • BOOTLOG_LOADED \SystemRoot\System32\drivers\raspppoe.sys
  • BOOTLOG_NOT_LOADED \SystemRoot\System32\DRIVERS\NDProxy.sys
  • BOOTLOG_LOADED \SystemRoot\System32\DRIVERS\ndistapi.sys
  • BOOTLOG_LOADED \SystemRoot\System32\drivers\ndiswan.sys

This is very interesting, as Microsoft strips out a ton of additional networking features as part of the boot-up process when it's enabled. The RAS stack, composed of NDProxy.sys, ndiswan.sys, AgileVpn.sys, and more, sits on top of the network driver layer and adds the following:

  • VPN tunneling protocols (SSTP, L2TP, IKEv2, PPTP, PPPoE)
  • Legacy WAN/TAPI compatibility
  • Service daemons such as RasMan (Remote Access Connection Manager)

All of these introduce kernel-mode networking hooks and user-mode background services that monitor interfaces and handle connection events, even when they're kept idle. By disabling what essentially amounts to an enterprise and legacy stack, Microsoft can reduce Deferred Procedure Call latency (DPC latency), it simplifies the overall networking stack, and improves boot times. And with fewer background services, it naturally follows that more RAM is freed up.

On top of that, all of the start-up applications are disabled, speeding up boot-times further, and many of the Windows UI elements aren't loaded into memory at all. These include the taskbar, start menu, and the desktop. Switching to the Windows desktop will load those elements, and other differences include disabling various background services. Devices like the Asus ROG Xbox Ally X boot directly into a fullscreen launcher (such as the Xbox app) which ultimately serves to replace those typical Windows shell functions while consuming less RAM overall.

If you're a developer, you can check whether FSE is active on a device by calling the IsGamingFullScreenExperienceActive() API, available in the April 2025 Windows SDK, and can register for notifications when players toggle it on or off. On top of that, you check whether it's currently active by calling the IsGamingFullScreenExperienceActive() API, also available in the April 2025 Windows SDK, and can register for notifications when players toggle it on or off. It's designed to be backwards compatible, meaning that if your game already works on Windows, it should work just as well in Full Screen Experience, too.

It's easy to enable

You just need some additional software

Enabling the Full Screen Experience is easy on any handheld with Windows 11, but to be honest, I don't see much point to just yet. I'm curious to see whether Microsoft will properly document how a developer can create their own launcher for users, but the fact you can choose a launcher suggests that it's expected you'll be able to change it at some point. What that looks like, exactly, is currently unknown, but the entire ordeal is an act to improve the Windows UI for handheld gamers, given that it's currently the biggest drawback of using a Windows handheld currently.

As well, there's the caveat that more might be going on behind the scenes on the Asus ROG Xbox Ally X than we can see on a device where the feature is forcefully enabled. However, given that Microsoft primarily touts memory improvements, and performance is more or less the same with it on or off, I would have doubts about that. It appears the big benefits are relating to memory usage, and that's about it. That's still nothing to scoff at, though; memory is important after all.