I have recently been attempting to create a GPIO Driver for SBC's using an Intel chipset that run Windows 8.1 and have begun testing it on an actual system. After loading the Driver and updating the Intel chipset I am using, the system appears to hang after loading the BIOS. Unfortunately, this disables my mouse, keyboard, and video, preventing me from entering BIOS or the boot manager.
While it is possible that the chipset update caused the system to become unbootable, it is highly unlikely considering we use that update for our other SBC's running the same chipset.
So my question: Is it possible for a Windows Kernel Mode driver to prevent a system from booting up past BIOS/POST?
I appreciate the help, since, clearly, I am no expert on this topic.
Yes, if your driver is being loaded at boot time it can prevent the booting of the OS and it will end up in BSOD(Blue screen of death) error with related bug check.
According to bugcheck displayed by the OS you can resolve the issues with your driver.
Or sometimes if its not giving any error and just hangs you can use WinDbg to check the bugcheck.
It depends on the error control of the driver service. Boot time drivers can also fail at any point. There is nothing special about the failure happening during boot. Instead, what is relevant under this scenario depends more on the ErrorControl value of the driver service which specifies how to proceed if it fails to load or initialize properly. A value of 3 (critical) would reboot the system to LKGC. Same rules apply to a win32 servic as well..
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 have to maintain a WDF driver. This is a no-hardware driver: the driver use a disk file which is mounted as a Windows partition. All the data written to the disk are encrypted by the driver. The driver run in kernel mode.
The driver has been developed on XP and successfully ported on Vista and 7, 32 & 64 bits. I encounter one big problem on Windows 8. The driver lead to a fatal system error:
BugCheck 50, {ffffffffffffffd0, 0, fffff800002de33a, 0}
Probably caused by : Wdf01000.sys ( Wdf01000!FxDevice::DispatchWithLock+fa )
The problem occurs after deleting the device with WdfObjectDelete(). As long as the device is not deleted the driver run fine and there is no system error. When WdfObjectDelete has been called, the system crashes after a certain delay.
verifier detects no error in the driver. My questions are the following:
Is there anything special regarding WDF on Windows 8?
Is there any tool/technique that could help me finding the bug in the driver?
There shouldn't be anything specific to Windows 8 for this issue. I'd recommend starting to debug your driver with WinDbg via a remote system. With this you can set breakpoints, step through the code and most importantly get post-mortem information on the crash. Once you have connected a machine, and you can see they crash use analyze -v to get information. OSR is a great resource for BSOD debugging.
I am new to windows driver development, so please bear with me if my question is being too stupid. Well, I am not sure why, as MSDN suggested and also the way I perceived, the host computer, e.g developing the driver, and the target computer, e.g debugging the driver, need to be two separate ones. why such separation? I did try to merge those two by deploying and debugging a driver on the host computer, in which I am developing a driver, and it seemed work with no objection from windows. Thanks.
PS. Source like this http://msdn.microsoft.com/en-us/library/windows/hardware/hh698272(v=vs.85).aspx got me think so.
Practically, when you are developing and testing a driver, in many situation you will get system crash (BSOD) and your system may not be bootable. In such situations your development + debugger environment is also gone/in-accessible.
Two separate machines are required for kernel debugging. You cannot debug self by obvious reasons (a debugger and a debuggee are in the same kernel and a deadlock appears). Of course, the target machine can be a virtual one.
When we develop a driver and test it the system will crash and a blue screen (called BSOD - blue screen of death)will show up. This is not the case like developing a User mode application and it crashed due to a memory error. Your driver will be running as a kernel mode application , If it crashes due to any illegal memory operation then the whole system is gone. It is not a simple issue to resolve , You need to log into safe mode and remove the driver from your system to recover it.
Due to this it is preferred to use a target machine mostly a VM on which the driver is installed and a host machine there we will be using a debugger to debug the driver.
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!
I'm curious about how, running Windows 7 on x86, you could execute some code in kernel mode. This is for my own personal use; so I'm not bothered about giving Windows a trillion permissions or whatever. Does kernel mode code have to be specially compiled or linked? etc
Only code from the kernel itself, and from certain device drivers, can run in kernel (supervisor, ring 0) mode.
So you will have to write a device driver.
EDIT: the question has already been answered here.
Ring 0 drivers can execute code in kernel mode.
You will need Windows Device Driver Kit for such development.
Also you have to be extremely careful with driver development because unhandled exception occurring in the kernel indicates a serious bug that exists in the operating system or (more likely) in a device driver and not in an application. Once memory in the kernel gets potentially corrupt, it isn't safe for the system to continue running and you see what is typically called "the Blue Screen of Death."
So normally your drivers should be WHQL certified.