I have a custom windows kernel driver I have compiled. I sign it with a test cert, create the cat file from the cdf, stamp the inx into a inf file, then load it with pnputil. I then create a software device with SwDeviceCreate so the OS will pair my driver and the driver. This works fine.
The problem is if i screw up something in the compilation and get something like an error code 39 (viewable in device manager), I do not see that error. Instead the OS seems to try to fix the error by loading the previously working version of the driver. In order to see that error, I have to purge the driver and device using pnputil /d oem42.inf along with a pnputil /remove-device, then restart my PC, that seems to fix the issue. This is difficult because it means i have to restart my PC every time i run a test. I know crashing a kernel driver can cause a panic anyway and cause me to restart, but there seems to be instances where this is not the case and the OS tries to rectify the issue without me (as it probably should).
So my question is this. Is there a way to completely purge my driver without a complete restart in-between installations/tests so I can correctly break it. I know I am suppose to use another machine and remote debug kernel drivers, but i do not have access to another machine right now that can support windows 11.
I've got a question for dos & win7 boot process.
Is it possible that dos boot and execute some dos-app before win7 boot without reboot?
I mean boot process like win95 or win3.1.
I'll explain more detail.
dos boot ->
execute some dos app ->
cleanup memory ->
load win7 volume boot record into memory 7c00 ->
win7 boot without reboot
Is this possible?
The scenario you have described is basically a warm reboot, interrupt 0x19 behaves almost like that, with the exception that it always loads the Master Boot Record (with the partition table). Win3.1 or Win95 were started as normal executables from DOS and not from their boot record. Win7 does not have any DOS phase during boot.
However, I think it's possible, but won't be easy. These are a few options:
The easiest solution would be if you can find an appropriate boot manager software that can do this for you. Take a look at GRUB and GRUB4DOS and this question.
If it is enough (the DOS program you want to run does not strictly require 16-bit DOS environment), I'm not sure, but maybe you can tweak Win7's boot.ini to boot in safe mode with command line and start it from there and then reboot.
In the worst case you must manually write a small DOS program that reads the Win7 boot sector to the address 0000:7C00 and executes it. For this to work you must now exactly where the Win7 boot sector is located in the disk. Be aware that on hardware that supports it, Win7 will prefer EFI boot method instead of the old MBR-based one. You must check what method your Win7 installation uses. There may be other difficulties like how to select active partition or that the DOS partition must reside in the beginning of the disk, and so on.
I'm developing a filter driver which works on top of an input device. Notably I'm testing it on my development machine (and yes, I know this is a bad idea).
On Windows XP whenever I needed to reload the filter driver, I'd just execute a batch file that would disable-enable the relevant devices through devcon, thus cause my filter driver to unload and reload.
However, on Windows 7 there seems to be a specific measure built against disabling the input device which your session is using. The option simply becomes unavailable in the Device Manager and even devcon no longer works. It does work from a remote desktop session, along with the kernel debug print "Trying to disable physical device not enabled in this session." (which hints that something explicit is allowing me to do this).
Is there a way to disable this functionality of Windows 7? Or perhaps a workaround you can offer to run my disable-enable batch file from an unrelated session?
Using Sysinternals psexec to run dpinst.exe works around this limitation. (Not sure why, since the DpInst UI is still being displayed.)
I'm setting up a test bed where I am testing a device connection across multiple Windows OSs. I can't do it in a VM (cannot virtualize access to device) so I have quite a multi-boot system. I have a script to automate the process, but I want it go ahead and finish, selecting the next OS to boot and run its test.
One problem is that XP/2K3 use boot.ini while Vista and later use BCDEdit. I could manually have two scripts... one for each XP/2K3 to edit boot.ini. And then to BCDEdit for Vista systems. I'd hate having to hardcode each one though, esp if I have to change order and/or toggle off certain OSs depending on the test conditions.
BCDEdit also uses GUID for their entries, meaning setting up on different machines would mean figuring out which GUID to go to next.
Any thoughts or hints? Are there any utilities that help automate this?
I'm assuming your various flavors of Windows are housed on different partitions. Use an Ubuntu LiveCD to install GRUB and write several configuration files, each of which has one OS selected as the default. Make a HD partition for /boot, and store the GRUB configs in the same location.
Each of your Windows partitions will need to install the Ext2 IFS driver, and mount the EXT2 partition you made before as z: or something. Then your test script can do something like:
mountvol z: %bootvolname%
copy /y boot_to_vista_64.lst z:\boot\grub\menu.lst
shutdown -r -f -t 0
%bootvolname% is a bit complicated, and is OS-specific. You'll need to store it with each OS partition, and you can get it by doing mountvol z: /l while that OS is running.
Does anyone know ways of partially or fully automating driver test installation?
I am new to driver development and am used to more of a test-driven approach in higher level languages, so moving to the kind of environment where I can't easily test as I go has been a step up for me. I am using Virtual PC for my test environment and currently have to reset it, open device manager, choose the device, click through a bunch of "Are you really sure you wouldn't rather install one of these system drivers" type dialogs, then finally reset the test environment while restarting WinDbg in the host machine just as the test environment is booting up... argh.
After repeating this process many, many times already, surely there has to be a be a better way of doing this? What tools/methods/tricks do commercial driver developers use to run up their driver in a test environment?
Note, this isn't about unit testing drivers, I haven't got to that stage yet or know if it is even possible. This is just about firing up a test environment with WinDbg attached to make sure that some small change I may have done is doing what I expect.
It seems to me that a virtualization software + a "mock objects" (layering) approach (as suggested by Aaron Digulla) + scripts (as suggested by Sergius) can simplify device driver development.
But if you use Visual Studio to develop user-level applications, you can use it for kernel device driver development too with VisualDDK (+ VirtualKD to debug over a named pipe, which is faster than over a virtual COM port), which addresses specifically the annoyances that you mention; from its home page:
... This project brings the simplicity and
convenience of Windows application
development to the driver development
world. No more manual creation of
build scripts, copying of driver
files, installing drivers from INFs,
switching between WinDbg and the
source editor or waiting for seconds
after each step due to the extra-slow
virtual COM port. Just create a driver
project using a convenient Driver
Wizard, select a virtual machine, and
enjoy debugging your driver directly
from Visual Studio. Want to test a
change? Just normally press Shift-F5,
modify your driver, rebuild it and
launch again. VisualDDK will unload
the old driver, install the new one
and load it automatically and quickly.
Bored with WinDbg loading symbol files
for minutes and looking up symbols for
seconds? Just let VisualDDK optimize
this for you using its own DIA-based
symbol engine. Using C++/STLPort in
your drivers? VisualDDK will natively
visualize all STL containers and
strings, as good as Visual Studio does
for user-mode applications. ...
You can write some shell scripts (using sc.exe and devcon.exe) to automate deployment tasks (no opening device manager, clicking on buttons, etc). And make snapshot of the system ready to debug (needn't wait for system boot).
Don't forget to check your driver with DriverVerifier!
Example of my own script :)
sc create FsFilter type= filesys binPath= c:\FSFilterDrv.sys
sc start FsFilter
pause
sc stop FsFilter
sc delete FsFilter
Follow the advice I gave here. Basically, test as little as possible with the real system.
In your case, I've got another tip: Virtual PC is using a virtual hard disk (that's probably a file on your real hard disk).
You don't need to install your driver, you can simply replace the new files in the virtual hard disk. This is often not possible in the running system but in a virtual system, you can open the virtual disk file and change it (since Windows isn't locking the files in it).
I'm not sure about Virtual PC but other emulators come with tools to work with virtual disk images. If VPC can't do it, check out VirtualBox.
It all depends a little on what kind of driver you are writing. But in many cases, writing an appropriate makefile (or something similar) that handles driver installation, start/stop, and launching of a test harness can already be good enough.
I also configure all of my test machines to automatically logon (AutoAdminLogon), map net drives, and launch an appropriate command prompt after startup. Running a specific test is then a matter of typing in a single command only.
One word concerning VirtualPC: VirtualPC is very handy for kernel mode development, but do not forget that it emulates a uniprocessor machine only -- so be sure to regularly test the code on a multiprocessor machine as well. That said, the VHD trick may seem handy, but it somewhat ties you to Virtual PC -- writing appropriate scripts that equally work on VirtualPC as on a real machine therefore seems a better approach to me.
Finally, consider it a shameless plug, but if you are looking for a unit testing framework for Windows kernel mode code, I have written one: cfix.
I think the DevCon utility (described in this OSR Online article) will help you. You should be able to setup batch files that do the job on one click.
It's free to sign up with osronline.com, and you'll probably have to sign up to get to that article. And if you are writing drivers, you WANT to sign up. These guys have been doing this for a long time, and there's a LOT of really good info on that web site.