I'm looking for a testing framework for the Windows kernel environment. So far, I've found cfix. Has any one tried it? Are there alternatives?
Being the author of cfix, I might be a little biased here -- but as a matter of fact, I am currently not aware of any other unit-testing framework for NT kernel mode.
If you should experience any problems with cfix, feel free to contact me.
Microsoft Static Driver Verifier is described as "a compile-time tool that explores code paths in a device driver by symbolically executing the source code. SDV is a unit-testing tool for Microsoft Windows device drivers based on the Windows Driver Model (WDM)."
Is that what you're looking for?
Related
What is needed to design on windows a driver for bluetooth mouse?
Do I need to use .NET framework for that? and do I need to create my own code from scratch is there an existing windows-based api for designers
You will definitely need the Windows Driver Kit to provide you with the necessary APIs.
And .NET won't come in handy there, you will be working with pure C, maybe C++.
Additionally you will need to know about the BT-stack, which is proprietary. Creating Drivers is no piece of cake, definitely. Maybe look for a user-space BT-library.
Installation of a device Driver on Windows 8 Fails with the following error:
0xe000022d -536870355 ERROR_NON_WINDOWS_NT_DRIVER
The decimal number was what I found in the error log (C:\Intel\Logs\IntelGFX.log), and a web search turned up the error Symbol Name.
As I downloaded the Driver straight from Intel (Intel® Graphics Media Accelerator Driver for Windows* XP), I do believe that it is an NT Driver. Just not for Win7 or Win8, but for XP and possibly adapted for Vista.
The device in question doesn't do Aero, but I don't Need Aero, so turned it off. I would, however, love to have the native Resolution and Hardware acceleration. Which is why I would love this Installation to succeed.
My assumption is that the Driver Installation Routine (the Intel Driver Setup program) interacts with the operating System in some ways in order to determine how exactly to install the Driver, and by way of prudence it barfs at the first sights of Errors; so that in theory a user who deems he knows better should be able to force the Installation. (It's only a preview System with no real data or functionality at the Moment, so why not Play around a Little.)
(1) Any idea what this error really means?
(2) Any way to Bypass the regular Driver Installation? Sort of force-install the Driver?
(3) Pointers like "What every programmer Needs to know about device Drivers" are also welcome, as a fallback to #1 and #2.
I found this error code documented in the SetupAPI on the DIF_ALLOW_INSTALL request page, but I know next to nothing about this API.
Okay, Ken's arguing this is not a programming question, and he might have a point. Trouble is: hard for me to make the programming point due to my lack of knowledge in the Driver department. This much I know: The Win32 API allows you to Register code to run when API routines get called. This is called "hook" in programmer lingo, and it's a concept I'm familiar with. The idea would be that you could somehow insert some code between the OS and the Driver Setup Routine to return "all great, go on" instead of ERROR_NON_WINDOWS_NT_DRIVER. But I've never done that at the System/Driver Level.
It is true that this is not a concrete programming question. Way to go for me to get there.
I posted this on stackoverflow because I deemed it too hard for superuser and off-Topic for serverfault. If you could suggest a better Forum that would also be helpful.
Hardware background: The Driver in question is for a 2005 vintage Hardware (Samsung X20 notebook) featuring an Intel 915GM/GMS, 910GML chipset. Not enjoying Hardware Support and falling back on some VGA Driver is obviously somewhat detrimental to the overall user experience.
(I excuse for undue capitalization in this post - this is due to the new spell-checker in IE10 which I haven't managed to disable yet.)
I'm creating an application that needs to use some kernel level modules, for which I've divided the app into 2: one user-level program and one kernel level program.
After reading about device drivers and walking through some tutorials, I'm a little confused.
Can there be a device driver without any specific device associated with it? Is there anything other than the device driver (kernel code or something) which works in kernel mode?
How do anti-virus programs and other such applications work in kernel mode? Is device driver the correct way or am I missing something?
Yes, device drivers can work without an actual piece of hardware (i.e. the device) attached to the machine. Just think of the different programs that emulate a connected SCSI drive (CD-ROM, whatever) for mounting ISO images. Or think about TrueCrypt, which emulates (removable) drives using containers, which are nothing more than encrypted files on your hard drive.
A word of warning, though: Driver development requires much more thought and has to be done more carefully, no shortcuts, good testing and in general expects you to know quite a good deal about the Windows driver model. Remember that faulty and poor drivers put the whole system's stability in jeopardy.
Honestly, I don't think reading a tutorial is sufficient here. You might want to at least invest in a decent book on that subject. Just my 2 cents, though.
Sorry, but the Windows Internals book is more of a general reading for the curious. I cannot recommend it if you want to engage in driver development - or at most as prerequisite reading to understand the architecture. There are plenty of other books around, although most of them are a bit older.
Depending on your goal, you may get away with one of the simpler driver models. That is not to say that driver development is trivial - in fact I second all aspects of the warning above and would even go further - but it means that you can save some of the more tedious work, if instead of writing a legacy file system filter you'd write one based on the filter manager. However, Windows XP before SP2 did not have it installed by default and Windows 2000 would require SP4+SRP+patch if I remember correctly. WDF (Windows Driver Foundation) makes writing drivers even easier, but it is not suitable for all needs.
The term device is somewhat of bad choice here. Device has a meaning in drivers as well, and it does not necessarily refer to the hardware device (as pointed out). Roughly there is a distinction between PDOs (physical device objects) and CDOs (control device objects). The latter are usually what you get to see in user mode and what can be accessed by means of CreateFile, ReadFile, WriteFile, DeviceIoControl and friends. CDOs are usually made visible to the Win32 realm by means of symbolic links (not to be confused with the file system entities of the same name). Drive letter assignments like C: are actually symbolic links to an underlying device. It depends on the driver whether that'd be a CDO or PDO. The distinction is more of a conceptual one taught as such in classes.
And that's what I would actually recommend. Take a class about Windows driver development. Having attended two seminars from OSR myself, I can highly recommend it. Those folks know what they're talking about. Oh, and sign up to their mailing lists over at OSR Online.
Use Sysinternals' WinObj to find out more about the device and driver objects and symlinks.
As for the question about AVs, yes they use file system filter drivers (briefly mentioned above). The only alternative to a full-fledged legacy FSFD is a mini-filter.
It is possible to load a special kind of DLL in kernel mode, too. But in general a driver is the way into the kernel mode and well documented as such.
Books you may want to consider (by ISBN): Most importantly "Programming the Windows Driver Model" (0735618038), "Windows NT Device Driver Development" (1578700582), "Windows NT File System Internals" (0976717514 (OSR's new edition)), "Undocumented Windows NT" (0764545698) and "Undocumented Windows 2000 Secrets" (0201721872) - and of course "Windows NT/2000 Native API Reference" (9781578701995) (classic). Although the last three more or less give you a better insight and are not strictly needed as reading for driver developers.
Anti-virus (and system recovery) software generally make use of file-system filter drivers. A device can have multiple filter drivers arranged like a stack, and any event/operation on this device has to pass through all the stacked up drivers. For example, anti-viruses install a filter driver for disk device so that they can intercept and scan all file system (read/write) operation.
As mentioned in above post, going through a good book would be a nice way to start. Also, install DDK/WDK and refer the bundled examples.
In a nutshell, I want to write my own device driver for windows, so that I can emulate a piece of hardware. I know very little about writing device drivers for windows, but I have a very firm understanding of the C and C++ languages, and I know enough x86(_64) assembly to get around.
I'm not really sure how one would go about even compiling a device driver, or what is required to create one. I'm certainly not against coding the entire thing in assembly if that needs to be done, but does it?
I'd like to do this using Windows tools obviously, I'm planning on trying to put it together using a windows GCC compiler, but I've got access to Visual Studio if that's needed. Can someone point me at resources that would be helpful, like reference manuals, tutorials, specs?
Oh: My target OS here is Windows 7, 64bit, which if I understand should be the same as Windows Vista 64bit, but correct my wrongness if it exists.
Thanks.
Everything you need to build your driver (including the compiler) comes from the WDK. Everything you need to know what to write comes from Walter Oney's books. Be prepared for a rough ride.
I am trying to learn a little about driver development and my question is, which OS has an easier API to develop drivers with? Windows or Linux?
Remember that I am new to this.
Thanks
If you are doing this for learning (I guess its your case), then go for Linux, you will have a more general ideal on how an OS works, you will interact with low level implementation straight to the core.
If you are just writing a driver for a device, I recommend using Visual Studio under Windows, it has a lot of features that will really help on your devel.
I am pretty sure you'll get lots of Windows vs Linux war here, unfortunately.
On Windows, you'll get pretty good development tools, with some awkward stuff, but that you can get along with easily. API is documented provided you have access to a Windows Developer account. Remote debugging is supported and it helps a lot for these kernel stuff that are triggering BSOD so quickly.
On Linux, you'll need to get your hands more dirty. Rubini's "Linux Device Drivers" is a very good starting point. Openness will bring you more flexibility, and more understanding of what is happening.
This tutorial might be helpful.
It is about writing a simple device driver for linux.
My personal idea is Linux. You can see the entire code other than an API.
I think Windows is good.
Because it has a rich set of API's which is easier to use