Home / Requirements
Version 3.221 · 64-bit Windows 10 and 11 only
Solara Executor runs on 64-bit desktop Windows and depends on two things it does not ship with: the x64 .NET Desktop Runtime and a working installation of the official Roblox Player. This page lists the hard requirements, explains the runtime dependency in detail, and sets out which platforms are out of scope.
Every row below is a requirement rather than a recommendation. If one is unmet, the application either fails to start or fails at the attach step, and both failures are quiet enough that people blame the download instead. Check the list before you visit the download page.
There is no minimum CPU model, RAM figure or free-space number published for this release, and this page will not invent one. The honest formulation is that a machine already running the Roblox Player acceptably has room for a desktop application alongside it.
| Component | Requirement |
|---|---|
| Operating system | Windows 10 (64-bit) or Windows 11 (64-bit) |
| Architecture | x86-64 only — no ARM64, no 32-bit |
| Roblox | Official Roblox Player for Windows, installed and working |
| Runtime | .NET Desktop Runtime (x64) |
| Permissions | Administrator elevation for the attach step |
| Archive tool | Windows Explorer or 7-Zip |
The application is built against .NET and does not bundle its own copy of the runtime, so the runtime has to be present before the first launch. This is the most common blocker for a first-time setup, and it produces the least helpful symptom available: you double-click the executable, the process appears for a moment, and then it exits. No window, no error dialog, nothing logged where you would look.
That silence is why the case gets misdiagnosed so consistently. People conclude the archive was corrupted in transit and download it again, or that antivirus quarantined the binary and start switching protections off — neither of which is happening. A managed application that cannot find a compatible runtime host has nowhere to report the problem, because the code that would have shown you a message box is the code that never got to run. If your launch is silent, treat the runtime as the first hypothesis rather than the last.
Two details about which runtime matter, and getting either wrong reproduces that same silent exit. You need the Desktop Runtime, which includes the Windows desktop UI components — the ASP.NET Core Runtime is for server workloads and does not contain them, and the plain .NET Runtime is not sufficient either. You also need the x64 build, because the executor is x86-64 and a 64-bit process cannot load a 32-bit runtime. Installing the x86 Desktop Runtime by accident leaves you with something installed that still cannot host this application.
To see what is present, open a terminal — Windows Terminal, PowerShell or Command Prompt — and run dotnet --list-runtimes. Each line names a runtime family and a version; the one you want begins with Microsoft.WindowsDesktop.App, with a path pointing into the 64-bit Program Files location rather than the x86 one. If the command is not recognised at all, nothing from the .NET family is installed.
User Account Control is the Windows mechanism that keeps a program running with ordinary privileges even when your account is an administrator. Elevation — the prompt that dims the screen and asks for confirmation — is what grants a process the higher privileges it would otherwise not have. Solara Executor needs it because attaching means opening a handle to memory belonging to another running program, which Windows does not permit at the default integrity level.
The consequence is worth stating plainly: a standard user account that cannot elevate cannot complete the attach step. On a managed device — a school laptop, a work machine, a child account — no setting in the application substitutes for a right the account does not have. If the prompt asks for administrator credentials you do not hold, the setup ends there.
Elevation applies to a single process launch rather than to the installation, so Run as administrator has to be used every time, not just the first time. Right-clicking the executable each session works; alternatively, create a shortcut, open its Properties, and set the compatibility option that always runs it elevated. The install guide places this correctly in the sequence: elevate at launch, with the place already loaded, and attach once rather than repeatedly.
The supported target is deliberately narrow, and the exclusions below are absolute rather than untested. In each case the required build does not exist in this line, so there is nothing to try.
32-bit Windows is out because there is no x86 package. Windows on ARM is out because no ARM64 build exists, and while ARM devices can emulate x64 applications, an executor's whole job is precise interaction with another process's memory — emulation is not a foundation you want underneath that. Windows 8.1 and older are not documented targets, and Android, iOS and consoles are out because this is a Windows desktop application attaching to a Windows process.
Roblox Studio is a separate exclusion, and the one people hit in good faith. Solara Executor attaches to the Roblox Player, the client you use to join and play a place. Studio is a different application with its own process and its own built-in scripting environment, so pointing the executor at it does not produce a partially-working version of the same thing — it produces nothing. The FAQ covers the other scope questions that come up often.
Both supported versions work, but they do not behave identically around unsigned software, and the difference decides whether setup takes five minutes or an hour. On recent Windows 11 builds the relevant feature is Smart App Control: unlike SmartScreen, which warns and lets you proceed, it blocks unsigned binaries outright with no run-anyway path in the dialog. If it is enabled, the executable will not launch.
On Windows 10, version 22H2 is the documented baseline for this release, and it is worth knowing that Windows 10 no longer receives mainstream updates — a general consideration for the machine rather than something specific to this application. The Windows guide works through the version-specific behaviour in detail, and the safety page explains how to read a warning about unsigned software instead of treating the prompt as a verdict.
It is easy to read a requirements page as a promise about performance. It is not one. This is a desktop application attaching to a running game process, so while you use it, two programs share the same CPU and the same RAM that Roblox alone was already consuming. Nothing about attaching makes the game lighter.
A machine that already struggles to run Roblox smoothly will not run it better with an executor attached, and treating one as a performance fix is a category error. Once the requirements above are genuinely met, the remaining failure modes are almost always sequencing rather than hardware, and the troubleshooting page maps each symptom to its cause.