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?
Related
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).
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'm using VS 2012 and VM on same machine.
Host Win7_x64 and VM on same machine is again Win7_x64
Debug using VS 2012, i.e using VS and pipe serial connection on VM.
Everything is proper. I'm able to load driver on VM using VS's in built process to attach.
I've build, link and install KmdfSmall driver given on microsoft website onto VM
I've build, link and install another very small test driver onto VM.
Yes, all drivers are showing very properly into device manager of VM.
When ever I'm pressing break all onto host in debug mode into VS; all break points are also becoming read on .c and .cpp files.
But the question comes here when I pressed f10 for checking code flow "No Source Code Available " window is getting open.
Actually I'm not very much familiar that how and where it should go but as in normal C program case in VS during debug the pointer go ahead in source file so here in window device driver where it should go.
thus how to debug driver here and what should I check to understand that driver is installed properly and working fine.
Attaching few images to get better idea. It will let you know that how much I reached.
Here I'm trying to debug NOTHING driver of OSR online
http://www.osronline.com/article.cfm?article=390
Kindly guide me to the best direction of what to debug and how in this windows device driver.
One image is of host having VS and another image is of VM where driver has been installed.
Please help me to debug the driver and understand its working.
On target, disable the driver meanwhile keep the VS into running debug mode onto host.
Then restart the target, enable the driver as soon as enable the driver onto target
it will jump to VS running into debug mode onto host at the already settled breakpoint. then after just press F5 and go ahead.
regards
matt
I am developing a driver based on ddk sample "passthru" and I have trouble loading this driver in win7(x86 or x64). I have tested my driver in winxp (x86 and x64), and it works pretty well, but when I tried to load this driver into win7 (F8->Disable Driver Signature Enforcement), it seemed failed. Then, I tried the native passthru code, it also failed. I thought it failed because
I can not see any outputs using KdPrint fron windbg.
I can not see any useful information from system event.
I set a breakpoint on passthru!DriverEntry, it seems that DriverEntry has not been called.
My WDK is 7600.16385.1, and passthru is supposed to be compatible with win7. I compile passthru using command "build -cZ".
Could you help me understanding this problem, or any clue about why passthru not loaded in win7?
I have built this driver in win7 x86 checked build environment， and tested in win7 x86.
Solved: Actually, the driver has been loaded, but the output of KdPrint not shown in win7 by default, you should use KdPrintEx to specify message level, or modify registry to make debug message shown. Now I have no idea why bp failed either.
Normally you can't use a driver that was built for WinXP target on a Win7 machine. Rebuild for Win7 target.
Well your question is rather unspecific, but I see one particular problem here: Enabling test-signing and disabling kernel mode signing policy still requires you to sign the binary ... (after WHQL-tests MS would cross-sign the .cat file for the driver). Refer to this.
See:
For 64-bit versions of Windows Vista and later versions of Windows,
the kernel-mode code signing policy requires that all kernel-mode code
have a digital signature.
and:
The operating system loader and the kernel load drivers that are
signed by any certificate. The certificate validation is not required
to chain up to a trusted root certification authority. However, each
driver image file must have a digital signature.
These commands should allow to load a driver signed with anything
bcdedit.exe -set loadoptions DDISABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING ON
You don't mention what target OS you chose when building. Icepack mentioned it. You need to actually build for Windows 7 to make it work with the new NDIS 6.0. Simply loading a driver built for XP (and older NDIS version) may not work at all.
My suggestion, use DDKBUILD.CMD and build one driver with (free build, W7):
ddkbuild.cmd -W7 fre . -cZ
and one with (free build, WXP)
ddkbuild.cmd -W7XP fre . -cZ
the above command line already takes into account the WDK you have. Note that if DDKBUILD.CMD fails to detect your installed WDK you'll have to set the environment variable W7BASE to point to the folder in which the WDK is installed (the one with install.htm, usually something like C:\WINDDK\7600.16385.1).
I've got a driver for a custom PCI card, which builds and runs fine on XP. I'm trying to use this custom hardware on W7, and am trying to build and run my driver.
I've got the latest DDK from Microsoft, and build my driver for XP using Windows XP "x86 Free Build Environment". Everything installs & works fine. (Build using a DDK "build" command)
If I use the Windows 7 "x86 Free Build Environment" build environment, everything builds fine. I run it through the PREfast and staticdv code checkers, no errors from either. ( I get a couple of warnings about "The dispatch function 'FooFnc' does not have any __drv_dispatchType annotations" - are these likely to be the issue? )
When I install, the install starts OK (standard error about drivers not being signed), but gets to a certain point and then hangs, then fails with a timeout error. The device then shows up in device manager as installed. At this point the PC won't shutdown or boot, but hangs indefinitely. I'm forced to boot into Safe Mode and uninstall the driver from there.
So my question(s) are:
If there has been a change in the driver model between XP and W7, what's the best way to find it? I can't see anything on MSDN.
How would I go about debugging the driver? The box doesn't start, so it's not like I can run up WinDBG.
Any specific W7 driver gotchas that are hidden away?
I've tried to keep this as generic as possible, but if more detail would be helpful I'll provide more
AFAIK, the biggest changes have been made in video and network drivers. Other drivers retain backward compatibility and can be run on W7 even with no recompiling.
Run your driver under driver verifier and turn on generating crash dumps with a keyboard (very helpful in case of system hangs, you can manually generate crashdump, analyze it and find what was wrong).
Hope this helps!