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.
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.
The Windows Sandbox is basically a virtual machine, so you can load drivers into it as long as they do not need to interact with hardware.
But there is also one extra limitation: there does not seem to exist a way to disable the drivers signature check in the Windows Sandbox, as this requires a restart which is not possible for the sandbox. Thus, your driver has be signed to be loaded and tested.
EDIT: the Sandbox supports rebooting since Windows 11 Build 2250, so it should be possible to disable the drivers signature and install custom drivers now (cannot test though, still on W10).
Related
I'm remote-debugging a Windows kernel-mode driver using WinDbg. The driver has issues in the initialization routine, leading to a bugcheck/crash when installing the device driver. When I detach the debugger, the target PC reboots and runs again into the same bugcheck.
In order to test a new version of the driver, I therefore have to boot into safe mode, uninstall the device using device manager and reboot into normal mode.
Is there any way to simplify this workflow so that the device driver is automatically removed upon rebooting after a bugcheck?
Additional infos:
I'm using dpinst to install the driver on the target PC
use .Kdfiles to pull a replacement driver during boot
Documentation From MS
Write Up in Nt Insider From Osr Online
if you are using windows 10 then you can leverage the -m option to provide a partial name
and forego the dospath C:\ NtPath \.\xx , %SystemRoot%
confusions in the map file formats ,
or as described here
I am using VS 2015 to learn windows driver development.code & compile are ok.
But i can not debug on target machine via net.
here are the output of vs:
----------------------------------------------------------------
[22:12:32:074]: Gathering kernel debugger settings
[22:12:32:080]: Removing any existing files from test execution folder.
[22:12:32:446]: Copying required files for "Gathering kernel debugger settings".
[22:12:37:967]: [Gathering kernel debugger settings] Command Line:
$KitRoot$\Testing\Runtimes\TAEF\te.exe "%SystemDrive%\DriverTest\Run\DriverTestTasks.dll" /select:"#Name='DriverTestTasks::_LogDebuggerSettings'" /rebootStateFile:%SystemDrive%\DriverTest\Run\DriverTestReboot.xml /enableWttLogging /wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Run\Gathering_kernel_debugger_settings_00013.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*" /runas:Elevated
[22:12:41:624]: Result Summary: Total=1, Passed=1, Failed=0, Blocked=0, Warned=0, Skipped=0
[22:12:41:624]: Task "Gathering kernel debugger settings" completed successfully
-------------------------------------------------------------------------
then i got a alert:
"failed to create process instance prevents debugging"
and then nothing happens.
what can i do to debug my driver on target machine?
Thanks a lot!
Visual Studio for remote kernel-mode debugging of your own device driver can be a huge pain sometimes; I've seen many experienced kernel-mode engineers stop wasting their time trying to get it to work in the past.
Make sure that you have the same version of Windows Driver Kit (WDK) installed on the Target Machine as you have installed on the Host Machine. Then try again and see if that solves the problem. You also need to make sure that you're signed into the WDK User Account which is automatically created at the start of Target Machine provisioning, as well as Debug Mode being enabled from boot.
If you cannot get it working properly after maximum a week, you may as well not bother wasting your time even further. You can use WinDbg (comes with the Windows Driver Kit as part of Debugging Tools - Visual Studio uses the WinDbg engine for debugging) to remotely debug the kernel of the Target Machine, and you can also use this for setting break-points/analysis of your own device driver. You'll just have to compile your source code and copy across your compiled driver/s to the Target Machine each time manually, which isn't all that bad thanks to shared folder features over a network/virtual machine.
I am working on this example on writing a simple Windows driver and debugging it from VS:
https://msdn.microsoft.com/en-us/library/windows/hardware/hh439665(v=vs.85).aspx
My Setup
Host: Windows 7 Physical system
Target: Windows 7 Physical system
Connection type: Serial cable (USB to serial in host, serial in
target)
Provisioning the target system is successful. Serial connection parameters are correct (tested the serial connection with different software). Driver is built and installed successfully in the target but "Break all" command does nothing. I am able to attach to a different process in the target.
I have seen similar questions and the usual response is to check for a mismatch between the connection parameters in the host and the target. I have checked this and the parameters are correct.
I would appreciate any advice.
Thanks!
A Simple KDMF USB Driver is deployed on a target machine
Target Machine has a USB Sniffer installed
Target is Win 8.1 (x64)
Host is Win 2012 Ent (x64)
WinDbg Remote Debugging Toolset is used
Target is provisioned
Breakpoints are set using the Visual Studio
IDE Deployment succeed, no errors at setupapi.dev.log
The USB Sniffer shows the URB interaction triggered by the deployed KMDF USB Driver Indicating the driver is actually running.
Although the driver is running and the debugger seemed to be attached execution doesn't break at any of the breakpoints set.
The debugger doesn't automatically break once attached.
Manually Breaking execution and running "x *!" verify that the KDMF USB Driver is loaded.
Manually Breaking execution and running "x %Driver Name%!*" verify that the
KDMF USB Driver symbols are properly loaded.
Manually Breaking execution and running "bl" list no breakpoints
Having the above in mind, why does the debugger doesn't break execution at the pre-defined break-points? why does the WinDbg "bl" command list no break points although few are set using the Visual Studio IDE?
Re-provisioning/rebooting/... doesn't resolve the problem
Any help will be appreciated
Update
I have cleaned any residuals of the driver from the system ( including driver cache cleanup using pnputil.exe -d )
Only then, setupapi.dev.log say the following:
Verifying file against specific (valid) catalog failed! (0x800b0109)
{_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 09:09:16.117
...
Success: File is signed in Authenticode(tm) catalog.
{_VERIFY_FILE_SIGNATURE exit(0xe0000241)} 09:09:16.137
...
The driver IS SIGNED with a valid verisign certificate, is there any specific req for that certificate?
Should this cause the problem I am experiencing?
Currently I am working on signing a 64-bit driver for a USB tool which is used to scan areas of the skin.
My setup is like this:
DTM Controller and DTM Studio are
running on a Server machine (Windows
Server 2003 R2 SP2)
DTM Client running on a Client Machine (Windows 7 64-bit)
I have managed to run tests on the client, using DTM Studio, but I get a couple of errors and I´m not sure why but I have some ideas.
The failures I encounter are the following:
Run INFTest against a single INF
RunJob – Copy of CHKINF and INFTest Library Job
Could not find user specified INF files. Bailing out...
Could not expand user supplied list of infs into individual filenames.
Sleep Stress With IO
RunJob – Sleep_Stress_With_IO .
Device has issues and not ready for test. Device Problem Code is: 28
Disable Enable With IO
RunJob – Disable_Enable_With_IO
Device has issues and not ready for test. Device Problem Code is: 28
Common Scenario Stress With IO
Execute_Device_Status_Check_Script
Device has issues and not ready for test. Device Problem Code is: 28
When I located the INF file in DTM Studio and added the tests I received the error: „No devices using the specified driver“. This is off course correct as the machine running the DTM Client (Windows 7 64-bit) does not have the driver installed for the USB tool.
So my question is:
Do i need to install the driver for the USB tool on the client machine?
If that is needed then the client machine must run a different version of Windows which brings to me my next question:
Can I run Logo tests successfully for a Windows 7 64-bit OS when the Client (running DTM Client) is set up using a different OS?
I managed to answer my questions:
Do I need to i install the driver for the USB tool on the client machine?
Yes this is needed.
Can I run Logo tests successfully for a Windows 7 64-bit OS when the Client (running DTM Client) is set up using a different OS?
No. The client machine must be set up using the target OS.