I need one of the drivers to be idle (loaded on the device, but not being used at all) to get some statistics. I need to make sure that no threads/clients are using the driver. I am trying to see if there is a way to achieve this so I can programatically kill/deactivate the clients/threads, if any, that are using the driver to make sure it is idle. Please suggest.
If you are using Windows Embedded Compact 7, you might be able to use a filter driver which can be inserted in front of the driver you are testing. The filter driver can prevent any calls from reaching your driver, hence effectively leaving your driver idle.
Filter drivers are a new feature in Compact 7, so it will not help you if you are using an older version. See http://embedded101.com/Articles/Embedded101Article/tabid/75/ArticleId/28/Filter-Device-Drivers.aspx for an intro to filter drivers.
I don't fully understand. If you wrote the driver, you are the gatekeeper to every entry point into the driver. You can allow/disallow clients to call in however you want (e.g. semaphore, mutex, boolean flag, etc). You would know if anyone is "using" the driver because maybe someone called Open and not Close. Or a method like Read or Write would have been entered and not yet exited.
Related
I'm looking to write an application that will allow me to control music, etc with a remote control. The infrared receiver I have is built into my MacBook Pro which is running Windows.
What I want to know is how can I go about this? Most of the information I can find online is specific to writing Windows device drivers and I'm having trouble finding out how to use drivers that already exist for a device.
Is it absolutely necessary for me to write my own drivers or is there a way to use the drivers provided by Apple?
On Windows you communicate with a driver by first opening it using CreateFile and subsequently sending commands to it using DeviceIoControl. You need documentation for the driver's API though to understand what functionality is available through which control codes and what parameters they expect. Digging up that information is probably the hard part.
Is there any way to programmatically alter the 'BM Options Latency Timer' of a USB<->Serial adapter? Needs to work on embedded windows xp. Can be a .net 2.0 or native windows solution...
I think you are using an FTDI USB serial converter. Then you can use libftdi
And check out the Application Notes (especially AN232B-04) because they contain lots of useful information.
This is driver specific. Your best bet is to do what romkyns says and try to figure out where the driver stores this setting. You will probably need to close and reopen the serial port after changing the setting assuming you are able to find out how it is stored and are able to change it.
As of 2016, the advice in AN232B-04 may be outdated due to changes in the Windows driver infrastructure. Nowadays, there's a requirement to sign all files in a driver package, which means that editing values in a inf/cat file while otherwise using the stock FTDI driver is not possible without re-signing the driver.
If you're using libftdi, you can configure this value at runtime, as per rve's answer. If you prefer to use FTDI's own driver and Windows' standard COM port API, and you need to configure this value, you can still change it permanently and programmatically by editing the registry.
If you go this route, you need to change the DWORD value LatencyTimer under the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\FTDIBUS\VID_0403+PID_6001+KBxxxxxxx\0000\Device Parameters. KBxxxxxxx in this example needs to be replaced by the serial number of your device. You would need higher privileges to change this value, eg by raising a UAC prompt. The device driver may need to be restarted at that point for the changes to take effect, for example by unplugging and replugging the device.
I have a feature request on a project I work on, it is to integrate with a Paylife CC handheld, which has a USB connector to connect with the computer. I have the docs, and am reading up on it.
When I searched on google how to read/write to a usb device on linux, it said, use libusb.
I was wondering, is there another possibility? Can't I just open it like a file and write a stream to it, and read a stream from it?
I don't actually need to do anything fancy. I just need to write a string of control codes to the device, and it would be mildly nice to read back the ACK and Error codes. But since those are already displayed on the device screen, I don't have to do much with it, just deliver the total required for payment.
So my question is, what are my options?
The connected computer is a regular ol ubuntu linux box.
It is definitely possible when the device complies with one of the USB device classes -- drivers for them are universal.
If that's not the case, then you may stick with a manufacturer-provided or a third-party driver, given there is one and you possess enough of it's documentation.
If that's also not the case, libusb-1.0 is your resort, unless you want to write a kernel driver youself :)
When I used C# i was only able to access user-mode registry accesses.
Is it very difficult to access kernel-mode registry accesses using C++?
I recall reading somewhere I may have to create a dummy windows driver or something?
EDIT: Basically as a hobby project I wish to create a simple registry monitor. However, I do want to catch kernel mode (as well as user mode) registry accesses..... last time I did this, using C# I could not access the kernel mode activity.
There are two ways to achieve this:
Hook the relevant functions in the kernel - the traditional way - which requires a C/Kernel Driver. This is possible on x86 Windows, but on x64 Kernel Patch Protection will detect these modifications and shut down the system (with a bluescreen).
Build a registry filter driver - this is the now encouraged way to attack this problem and is the way process monitor works. You can also build file system filter drivers this way. Essentially, you simply need to pass the information back to userland which boils down to:
IoRegisterDevice(...somewhere in \Devices\YourDriverName...)
IoCreateSymbolicLink(\\DosDevices\Name -> \Devices\YourDriverName)
then a C, C++, C# application should be able to open the file \\.\YourDriverName and DeviceIoControl to it and receive responses.
It is possible to use C++ to write kernel drivers, but see this before you embark on doing so. To be clearer, you need to be really careful about memory in kernel mode (paged, nonpaged) and you're not going to have access to much of the standard library.
As an aside, you should be aware that:
Not all registry hives are accessible to kernel mode drivers, depending on context.
The paths are not common. So the kernel accesses \Registry\System whereas userland accesses HKLM.
i need to add some files to results returned by FindFirstFile and FindNextFile under windows. Is this possible by file system filter driver or what type of drivers?
Thank you
You can do this by File System Filter Driver. But you can do this by implementing a system wide API hook. I have not tried it before but you really don't need to take the pains of writing the drivers and making the system unstable in case of spoiling the driver stack.
System Wide API Hooking
API Hooking Revealed
As pointed out you can use a file system filter driver (legacy or mini-filter, based on fltmgr). However, I would strongly recommend against the system-wide API hooking. Simple reason: if you do it in usermode it's not really going to be system-wide and if you use an SSDT-hook or some hotpatching method you risk the system's stability. An alternative, albeit equally shady as system-wide hooking, would be entry-point stealing. In this case you use the device object of the volume (in which you're interested, just listen for the attach notifications or enumerate them at startup) to find the driver responsible for it and modify the major function entry points in the driver object (Ilho pointed you into the right direction already).
A file system filter driver is the supported method to do just that.
In the latest Windows 7 WDK the sample under 7600.16385.1\src\filesys\miniFilter\minispy provides a good starting point. Biggest problem with mini filters for a private person is to get assigned an altitude for the driver to load at. Because using just any altitude can well lead to BSODs - and in case of FSFDs you might even risk your data integrity (although the kernel steps in with the BSOD to prevent that). You only need to fake IRP_MN_QUERY_DIRECTORY - this is the minor control code you're looking for when you are handling the IRP_MJ_DIRECTORY_CONTROL major control code. All others you can pass through as long as you don't need to allow the file to be opened, read or written and such. How to do that can be seen in the 7600.16385.1\src\filesys\miniFilter\passThrough sample source.