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.
Related
I have a PCI driver for a FPGA card that installs and works fine.However, we have a need to clean up our system without rebooting which includes unloading this driver.
When starting again (without rebooting) the driver is re-installed. I have found that when I do this process (install/uninstall) multiple times, on the 5th unload of the driver the directory associated with the device just disappears.
lspci command can no longer find my device because of a bad link. I have to reboot to get the device directory (/sys/bus/pci/devices/00000:04:00.0) to show up again.
With some experimentation and reducing the driver down to the bare minimum I discovered that if I do not do a call to pci_enable_device(..) function in my pci_probe_method, then I am able to install/uninstall the driver multiple times without error.
Of course, I need to call this method before I can do anything with the device but I wanted to be sure it was not some other of the more complex initialization I am doing was causing the problem.
I have verified that my call to pci_disable_device() is being called in the pci_remove_method(). I should be able to enable and disable a PCI device indefinitely, right? Any help in figuring out what is happening would be appreciated.
The actual solution to this problem was to eliminate an extraneous call I had to pci_dev_put(..). I did not notice this before when submitting the question. This was leftover from when this driver was not using the pci_probe() method to discover this device. So, executing this call in the exit routine caused the structure for this device to go away after 5 calls. So for now this problem is solved.
I've added some code to the Windows Filtering Platform MSNMNTR sample for my own application, but it still has the same structure. I've compiled the driver and the application for Win8 64-bit and production-signed the driver. On the (virtual) machine that I built the code on, the sample works fine and monitors correctly. When I copy the inf, sys and exe to another machine, the sample does NOT monitor. Through traceview output, I can see that on the second machine, DriverEntry() is not called, therefore the flow controls are never set up. The two machines are running the release version of Win8. It doesn't appear to be an issue with my new code, since the driver works fine on machine #1, and it doesn't appear to be a signature problem because when I turn off signature enforcement on machine #2 I still have the problem. Both the release and debug versions of the code have the same issue. The steps I use to set up and run the code are below. What are some things that might cause this behavior?
Copy driver .pdbs to a folder for traceview.
Right-click .inf and choose "Install"
Run "net start msnmntr" from an elevated command prompt.
Start traceview as administrator.
Run "monitor monitor "C:\Program Files\Internet Explorer\iexplore.exe"" from an elevated command prompt.
P.S. I haven't put windbg on this yet, but I will update the question with the results as soon as I try it.
Edited to add: OK, I ran the kernel-mode debugger on both machines and saw a difference in behavior. First of all, DriverEntry does get called on both machines. I was mistaken about that. However, on the machine where the code works (i.e. monitors web traffic) DriverEntry gets called when monitor.exe is run (step 5 above), and on the machine where the code does not work DriverEntry gets called when "net start msnmntr" (step 3 above) is executed.
The problem was that I had not installed the callouts via "monitor addcallouts" on the second machine. Since this is a one-time step, I had forgotten I did it weeks ago on the original machine.
Switched development to 64bit windows and I'm having an issue. After I quit the executable it is still locked for at least 5min and sometimes until I reboot. So I can't do a new build, which makes development a little slow and frustrating.
Filelock reports it to be locked by "system" (helpful) and can't unlock it, even running as admin. It doesn't appear to be runni=ng in procexp or taskmanager.
This is a C++ app using Qt, with vs2010 pro on Windows7 pro 64bit - not sure if any of those are the problem, it was fine on 32bit.
Has anyone else seen anything like this?
I frequently have similar problems, which in my case are caused when I'm debugging an application that uses a MIDI device. If the app crashes or I stop debugging (ie stopping in the debugger, rather than letting the app finish normally) then one driver on my system doesn't release the device. The process resists all attempts to kill it. Either I have to disconnect the device temporarily (so the driver gets released) or reboot. As a workaround I can usually just rename the .exe which means that I can link again, though I end up with lots of zombie processes.
So the first thing to check is whether there are any particular I/O devices you're using in this app, and whether the drivers are up to date. If you don't think there's any specific drivers you're using then try running windbg, attach to the process and type !analyze -v -hang. This may tell you which driver dll it's waiting on.
Probably a stupid idea- But try changing the file ownership to you again, and turn on "Take Ownership" in the file system settings.
It is annoyingly common to own a folder, and not all the files inside it.
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 debugging an audio driver under Windows 7. When I need to replace it with an updated version, I have to reboot the system because a copy of current driver under DriverStore is locked despite the fact that the driver is unloaded. Is there a way to avoid rebooting? It was possible on XP...
Do you tried to stop driver with devcon.exe utility (an old version can be downloaded also in http://support.microsoft.com/kb/311272, a new version you find under C:\WinDDK\7600.16385.1\tools\devcon\i386 after intalling of WDK)? Do you examine which processed use your driver (for example with respect of Process Explorer http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx)? If you describes your problem more exactly I could try to help you.