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).
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
Before I ask my question, here's some background information so that you might have a better understanding of what I am trying to accomplish. I have searched around and found similar questions but none that are specifically what I am asking.
I am trying to port over a modified 32-bit PLX Pci9056 device driver to 64-bit. I also have a few User apps that utilize the driver. PLX provides a complete SDK, including the PLX API in a dll, driver source code, and tools to create and debug user apps. It uses the Windows DDK build environment to build the drivers. The following is how they all interact:
User app --> PLX API --> PLX Pci 9056 driver --> PLX chip
The 32-bit driver has been tested on Windows 7 32-bit and works properly. I believe I should be able to simply rebuild the driver in the 64-bit Windows DDK build environment (Of course after handling any pointer casting. Please correct me if I am wrong.) At this point the driver should run properly on a 64-bit Windows 7 machine.
I understand that usually 32-bit apps will run fine on a 64 bit machine, but in this case the User app is using the PLX API which was initially built only to support 32-bit. Will my User app still work in a 64-bit OS without updating it, or will I run into issues?
The PLX PCI SDK (now Broadcom PCI/PCIe SDK) has supported both 32b/64b drivers with the same source code for many years now. Special macros are used when required, etc. In Windows, your 32-bit app will work fine due to WOW layer. The PLX IOCTL structures always store pointers in 64-bit fields to ensure the structure does not vary if you build a 32-bit app. The SDK also provides 64-bit build of the API library, so you can also build your app as native 64-bit. The same app level source code, for the most part, should work in both Windows & Linux. The samples provided in the SDK are all identical source for both Win/Linux.
I am trying to use ObRegisterCallbacks to prevent my app being terminated.
in windows 7 x64 system, it works well as my plan.
but in windows 7 x86 system, there are some problems.
I have to link my driver with /INTEGRITYCHECK linker option, or I couldn't use ObRegisterCallbacks function. It returned ACCESS_DENIED.
but if I build it with /INTEGRITYCHECK linker option, I couldn't load my driver.
when I call StartService(), it returned ERROR_INVALID_IMAGE_HASH.
Of course, I had signed my driver after build. so my driver file had a digital signature on binary.
However it still returned ERROR_INVALID_IMAGE_HASH.
and if I built with same sources for x64 platform, it works fine.
furthermore, if I boot my PC(x86) with Test Boot Mode , it works well too.
I am wondering that is possible to use ObRegisterCallbacks on x86 system ( not test boot mode ).
Any reply will be appreciated.
It works for x86 system you need to sign your driver using certificate , Testsigning does not work so make sure you have certificate using makecert tool.
use signtool to sign your driver withthe certificate you created
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!
We have an application which uses the RNDIS USB driver, aka "Linux USB Ethernet/RNDIS Gadget" to talk to a linux based embedded device.
We have digitally signed (with a Verisign certificate) this driver for use with Windows 7. This eliminates an "unsigned driver" error message on install.
On XP, however, even a signed driver displays a "Linux USB Ethernet/RNDIS has not passed Windows Logo testing..."
This is, evidently, a driver developed by Microsoft. I saw reports that this and other drivers were signed in SP2 and this broke in SP3.
The goal is to do an install of the driver without a warning or error. Is this driver, or a compatible driver, available anywhere else? Is there a way to get it signed through WHQL?
According to http://en.wikipedia.org/wiki/WHQL_Testing:
A company can choose to sign their own drivers rather than go through
the WHQL testing process. These drivers would not qualify for the
"Certified for Windows" logos, but they would install on 64 bit
versions of Windows and install without a warning message on 32 bit
versions of Windows Vista or Windows 7.[2] However, it will not
install without a warning message on Windows XP.[3]
I read something somewhere about how to get around this but can't find it right now. Can you not get it (or a renamed copy of it) signed through WHQL?