I have some source code with a driver called TVicHW32 and under Windows XP it works fine and the interrupt handler gets called every time there is an interrupt from the ISA bus card. The ISA bus IRQ on 5 is set as reserved in the BIOS.
If I run the exact same code under Windows 7 or even 10, the interrupt handler never gets called. I can see the interrupt line triggering with a scope but the code never gets called. I've even tried to run my code under admin and still the same.
I've emailed the company who supplies the driver but they are not replying. Is there something in Windows 7 or 10 that prevents access to the IRQ? IRQ5 is not used on this computer. This I have confirmed in the Device Manager.
Failing any chance to get a response from the company on this, has anyone got any alternative to handler hardware IRQ under Windows 7?
Related
I need to change the output buffer whenever a call to ZwDeviceIoControlFile is made. Is it possible to hook ZwDeviceIoControlFile from within a kernel mode driver in Windows 10 x64 while Patchguard is enabled? If not, could I maybe use ObRegister callbacks to change its output buffer?
Would like to know if someone ever succeeded with this on Windows x64 while PG is enabled.
I ended up writing a Hypervisor and using EPT to hide the actual hook when PG does a read operation on the region. I am able to fully hook kernel APIs without PG noticing on Win 10 x64.
I have some old serial based USB touchscreen systems that would be expensive to replace with new hardware.
They are connected in the following manner:
Serial Mouse -> Serial to USB adapter -> Thin Client -> Virtual Machine
Everything works great with one issue. I'm experiencing a driver crash everything user either logs off, shutdown, or reboots. The current workaround has been to disable the serial mouse device before logging off which is a real pain. As long as the device is disabled, everything works great.
I did a lot of research on this issue by taking memory dumps of the crash virtual machines.
It seems like when the user logs off, the USB device is abruptly disconnected and then Windows tries to disable the device gracefully and waits until it is confirmed, thus hanging forever. In assembly it appears to call a .sys file that never returns back.
Is there anything that can be done with an issue like that? Can you change the device shutdown order? Or perhaps tell Windows to not ensure the plug and play device is shutdown? I doubt the vendor would be willing to change their driver.
I wrote a custom solution to this problem.
The application uses the ShutdownBlockReasonCreate API call to block Windows from shutting down. It then listens for reboots or logoffs using the WM_QUERYENDSESSION API call. When it gets this, it disabled the devices and then destroys the shutdown block created.
A real pain but it works
i'm currently developing a KMDF HID minidriver for the Nintendo Wii Remote. My
HID minidriver replaces the HidBth minidriver for the HIDClass driver (I'm using
the KMDF HID minidriver sample, where it is actually a filter driver and uses
this "kmdfhidminidriver" to forward all requests).
So my problem is, when i power off the Wii Remote (pressing the Power button or removing the batteries), the PnP-Manager won't
recognize the device is gone. Windows still shows the device in the device manager and thinks everything is fine and
running. The only hint, that the device is gone is, that the L2CAP-Channel is
closed and i get the L2CAP-Callback called with Indicator Code
"RemoteDisconnect".
My question is, how do i signal the PnP-Manager the device has disconnected? I
tried using "WdfDeviceSetDeviceState" with "Removed" set to true. But then the
Device Manager shows an driver error (Code 24). I would like to have a solution,
where the device gets removed from the Device Manager without any error, like
unplugging an USB device.
Additional information: i'm using WDK 8 and WDF 1.11; driver target systems are
Win 7 and 8.
Ok, i have to use "HidNotifyPresence". It is prototyped in "hidport.h", but unfortunately not documented yet.
It takes two arguments. The first one is a device object, which might be the FDO. The second one is a BOOLEAN. If true the device will be re-enumerated, else the device is suprise removed.
Since my driver is a filter driver, i need to provide my own PassThrough (shim) miniport driver, which will pass the FDO and "HidNotifyPresence" addresses to the filter driver.
I need to set up USB communication between a Windows 7 host and a Linux device for data transfer. I was able to compile the Linux kernel on the device to include the Gadget Zero driver in the kernel (not as a loadable module - Linux version 3.0.15). My project has some requirements, which also explains why I chose Gadget Zero:
1) On the Windows 7 host, a kernel mode driver must be used to communicate over the USB connection for sending and receiving bulk data. (speed is not important, not a lot of data at once).
2) On the linux device, no requirements on USB side except send and receive data easily over USB link. The data received will eventually be "unmarshalled" to call functions in another kernel module (and those responses packaged and sent back to the host).
3) Multiple linux devices will be connected to the host, so need easy way to enumerate connected devices and communicate with them.
So due to the requirements, I decided against the Gadget Serial. I'm having serious issues sending and receiving data over the virtual COM port in kernel mode (KMDF) in Win 7 host. WinUSB does not seem to want to open my attached device (I'm using KMDF windows USB driver from template in VS2012) Also, the gadget serial driver on the linux side, I cannot find the functions where the data is received and sent. Plus, any received data on the linux device seems to be echoed back to the host for some reason. (and to test this, I wrote a simple user-mode app in Windows, which is a no-no for my project).
Gadget Zero, it appears much simpler on the linux side. I can plug the USB cable to the Win7 host, and I can get the device to appear in the device manager. However, again I am having problems with getting communication going over the link. Gadget Zero has 2 bulk endpoints, so this shouldn't be an issue. Surely, someone has made data communication possible between a Windows host and a linux device using Gadget Zero? With Gadget Zero, it should be easy to enumerate the connected linux devices and communicate with them.
The trick is to keep the Windows side communication in kernel mode. Can someone point me in the right direction perhaps with Gadget Zero, Windows 7 KMDF, and some sample source code? I have a hard time believing no one has done this before because my internet searches don't turn up much. (and mostly user-mode solutions with Gadget Serial).
Thanks!
So you're writing a Win32 driver in which you want to communicate with your linuxed usb? I haven't written much win32 kernel code, but I believe I've seen a huge section in the doc, saying something like "This is how you make usb drivers"... That'd be it. In other words, when in kernel mode you have access to the full kernel usb layer. You don't need an existing driver or whatnot.
On the linux side you can use the serial gadget, in a different run mode. Only the default run mode, registers it self as VCP. There exist a more basic mode:
modprobe g_serial use_acm=0
Give it your own vendor id and you'll be able to attach your very own custom win32 driver. The 'multiple linux devices' will be handled by Windows. (Multiple instances of your driver, will be initiated.)
The echo you're seeing btw, is most likely a terminal feature. (The terminal mode on uarts will echo.) You have to disable it, when connecting. And now that you're at it, you also have to disable the xon/xoff, esc chars etc. (Standard legacy rubbish.)
And another thing. I'm not sure the gadget zero actually sends the data onto the line. It's meant for testing the gadget framework. (I could be mistaken though.)
Anyway, you've prolly solved this issue years ago. I'd be nice to know what you came up with.
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.