For the past few weeks, I’ve been using a Surface Laptop 7 with a Snapdragon ARM64 CPU as my main development device. This device boasts excellent battery life, and I appreciate the built-in Copilot, which leverages the NPU for enhanced performance in some applications. I also have exciting plans to utilize Microsoft Recall once it’s available again.
In this article, I’ll share some important considerations and my experiences using an ARM device for development, particularly with Visual Studio, SQL Server, Docker, and more.
Using Visual Studio
Visual Studio 2022, starting from version 17.4, offers full native support for ARM64. Currently, I’m using version 17.12.0 Preview 4.0, alongside the released version 17.11.5. Visual Studio runs exceptionally well on this device. However, there are a few exceptions worth noting.
Using SQL Server
SQL Server is crucial for many projects built by my clients. SQL Server LocalDb comes preinstalled with Visual Studio:
However, using the ARM CPU, LocalDB does not run.
Attempting to install SQL Server Developer edition with the command:
winget install Microsoft.SQLServer.2022.Developer
results in this error:
Oops...
\
Unable to install SQL Server (setup.exe).
Exit code (Decimal): -2147467259
Error description: Unknown error (0xe0000235)
SQL SERVER INSTALL LOG FOLDER
C:\Program Files\Microsoft SQL Server\160\Setup Bootstrap\Log\20241027_113018
Installer failed with exit code: 2147500037
The detailed error log indicates:
ExecuteActionWithRetryHelper.Failed actionToExecute is 'SqlEngineConfigAction_install_confignonrc_Cpu64', stack trace at Microsoft.SqlServer.Setup.Chainer.Workflow.ActionInvocation.c__DisplayClass2_1.b__0()
The root cause is the ARM CPU. According to SQL Server 2022: Hardware and software requirements:
> Installation of SQL Server is supported on x64 processors only. It is not longer supported on x86 processors.
It appears that the installation programs for SQL Server are not compatible with ARM CPUs.
Interestingly, some users had success running SQL Server on Windows 11 on ARM with the help of this repo: MSSQLExpress-M1-Install.some Reddit users had success on running SQL Server for Windows 11 on ARM!
My next option was Azure SQL Edge. The documentation What is Azure SQL Edge for this great product lists this:
> Azure SQL Edge will be retired on September 30, 2025.
I try not to use products that will be retired soon. However, in this case it could have been my choice. Until that time we probably have support for ARM64 with SQL Server.
But in this case, there’s another important note:
> Azure SQL Edge no longer supports the ARM64 platform.
Switching over to the next option.
Using Docker
Docker Desktop now offers installation options for various platforms:
- Download for Mac – Intel Chip
- Download for Mac – Apple Silicon
- Download for Windows – AMD64
- Download for Windows – ARM64
- Download for Linux
I already had Docker Desktop installed on my Surface Laptop 7. In my book, Pragmatic Microservices with C# and Azure, Chapter 5 covers using Docker to run the sample solution with Docker containers. The app model utilizes the .NET Aspire SQL Server Entity Framework Core integration:
var sqlServer = builder.AddSqlServer("sql", sqlPassword)
.WithDataVolume("codebreaker-sql-data", isReadOnly: false)
.AddDatabase("CodebreakerSql");
var gameAPIs = builder.AddProject("gameapis")
.WithReference(sqlServer);
builder.AddProject("bot")
.WithReference(gameAPIs);
However, running the solution on the ARM CPU fails:
The logs show this error when starting the container:
/opt/mssql/bin/sqlservr: Invalid mapping of address 0x2aaaad74d000 in reserved address space below 0x400000000000. Possible causes:
1) the process (itself, or via a wrapper) starts-up its own running environment sets the stack size limit to unlimited via syscall setrlimit(2);
2) the process (itself, or via a wrapper) adjusts its own execution domain and flag the system its legacy personality via syscall personality(2);
3) sysadmin deliberately sets the system to run on legacy VA layout mode by adjusting a sysctl knob vm.legacy_va_layout.
A preceding warning provides another clue:
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
You can use the docker inspect command to get information about the downloaded image:
docker inspect mcr.microsoft.com/mssql/server:2022-latest
The results show the architecture:
"Architecture": "amd64",
"Os": "linux",
"Size": 578241111,
Attempting to pull a Docker image with the platform option set:
docker pull mcr.microsoft.com/mssql/server:2022-latest --platform linux/arm64/v8
still pulls the image for amd64, as the image for the platform linux/arm64/v8 is not available at this time.
You can discuss the Docker image for SQL Server in the MSSQL-Docker repo, where these issues are tracked:
which is not resolved yet.
> As a sidenote, Docker requires an operating system as its core, which also makes use of a CPU. Using WASI, an operating system is not needed, just a WASM runtime. With .NET 10, experimental WASI continues.
Switching over to the next option.
Using Azure SQL
Using Azure SQL is my next option. It’s straightforward to use Azure SQL for local development. However, I encountered an issue independent of the ARM CPU at a customer site where the network used IPv6 to access the Internet. Although I can configure an IPv6 firewall rule with the Azure CLI:
az sql server ipv6-firewall-rule
IPv6 is disabled with Azure SQL server resources at this time.
One way around this is to use a virtual network:
IPv6 for Azure Virtual Network is generally available
You can also check the Azure services where IPv6 can be configured.
Instead of configuring a virtual network for IPv6 support, I’ve been using my Intel-based Surface device to use SQL database.
Using multiple systems
Since the COVID-19 pandemic, when trainings moved online, I’ve found it beneficial to use not only multiple monitors but also two systems. This setup allows me to keep the attendees in view on one system while sharing my screen on the other. Additionally, I’ve used Windows Insider builds on one system while running a released Windows version on the other. This approach also provides a backup in case the hardware of one device fails. Currently, I’m using an ARM64 CPU on one device and an Intel CPU on the other.
This environment has been particularly helpful, allowing me to switch to the Intel device when using the SQL database on the local system.
More issues with Surface Laptop 7 with ARM processor
will be added here:
- Surface Laptop 7 does not support using a Surface Pen: Microsoft Pen not working on new Surface Laptop with Snapdragon ARM processor
> Using Paint with Copilot, the Surface Pen cannot be used.
Takeaway
The Surface Laptop 7th Edition, featuring the Snapdragon ARM processor and integrated Copilot, is a fantastic device. However, before making it your primary device, ensure that the applications and Docker images you rely on are compatible.
I own two excellent Surface devices, one with an Intel CPU and the other with an ARM CPU, and I’m excited about the increasing support for ARM. As of now, SQL Server (including its Docker image) and the Surface Pen are not available for ARM.
What applications do you use that don’t support the ARM CPU? Do you already own a Windows device with an ARM64 processor? What’s your experience with the applications you use
Enjoy learning and programming!
Christian
If you like this article, please support me with a coffee. Thanks!
More Information
More information about C# programming is available in my books and my workshops.
blogs.cninnovation.com 
Tried to use Surfce Pro 7 with Snapdragon CPU for .Net MAUI cross-platform app development. Failed!
First problem was a mistake on my part – you need Windows Pro to run Hypervisor, which is needed for the Android/iOS emulators. So I paid the extra to upgrade to Windows Pro, only to find there ARE NO Android emulators which run on Snapdragon hardware! Not the final straw as one can debug on an Android device connected via a USB port, but inconvenient.
The iOS emulator does run, but impossibly slowly. But surely one can go the same route and debug on an attached device? No. Hot Retsart technology not supported on Snapdragon hardware!
It would be less frustrating if any of these failures gave a simple “wrong cpu” error message. But they don’t, they give common error messages which lead to hours of debugging/posts on forums etc before someone finally says “It’s the CPU”.
Annoying!
LikeLike