Can the windows sandbox feature be used for driver testing?

Question

Doing windows driver development for first time, I want to deploy my first driver. But I don't have a second computer.

Microsoft docs:

Typically when you test and debug a driver, the debugger and driver run on separate computers. The computer that runs the debugger is called the host computer, and the computer that runs the driver is called the target computer. The target computer is also called the test computer.

I am starting with vhidmini2 as my project base (the UMDF2 version). I want to know if the Windows Sandbox feature can be used in place of test computer? My driver will not be interacting with any hardware.

Answer 1

You can set up Windows Sandbox for kernel debugging with CmDiag (undocumented, but mentioned by Jonas L):

First you need to enable development mode (everything needs to be run from an Administrator command prompt):

CmDiag DevelopmentMode -On

Then enable network debugging (you can see additional options with CmDiag Debug):

CmDiag Debug -On -Net

This should give you the connection string:

Debugging successfully enabled.

Connection string: -k net:port=50100,key=cl.ea.rt.ext,target=<ContainerHostIp> -v

Now start WinDbg and connect to 127.0.0.1:

windbg.exe -k net:port=50100,key=cl.ea.rt.ext,target=127.0.0.1 -v

Then you start Windows Sandbox and it should connect:

Microsoft (R) Windows Debugger Version 10.0.22621.1 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Using NET for debugging
Opened WinSock 2.0
Using IPv4 only.
Waiting to reconnect...
Connected to target 127.0.0.1 on port 50100 on local IP <xxx.xxx.xxx.xxx>.
You can get the target MAC address by running .kdtargetmac command.
Connected to Windows 10 19041 x64 target at (Sun Aug  7 10:32:11.311 2022 (UTC + 2:00)), ptr64 TRUE
Kernel Debugger connection established.

(When I set this up initially I was getting some error when starting Windows Sandbox and I had to reboot, but this might not be necessary)

A few times I got error 0x80070020, this seems to be because the port isn't available (perhaps reserved by Hyper-V?). Switching to port 12345 fixed it for me.