CODEWITHSUNDEEP
c#sys
hazzelnuttie
hazzelnuttie

Reputation: 1481

Access IO ports via windows driver from Visual C#

I have with me a Windows driver (.sys) format

I need to access this driver from Visual C#. When I try to add this driver as a reference from Visual C#, I get the below error "Make sure this is a valid assembly or COM component"

Edits The driver is to control WDT through IO ports and has IOCTL calls. How can I make use of the driver and set/reset watchdog using a VC# application?

I am new to VC# and would like you to provide ideas, that I can explore.

Thanks in advance.

Upvotes: 2

Views: 1061

Answers (1)

Dai
Dai

Reputation: 154995

Drivers in Windows are kernel-mode components, they are loaded by the operating system directly into kernel space (generally-speaking; certain drivers live in userland and can also live in virtual memory too, but those are exceptions). Your driver will have been (or rather: should be) installed by an installation program. Contact the vendor for installation instructions if you were provided with just a binary. Each driver has its own special installation steps so I cannot tell you how to install it.

For a userland process (i.e. your .NET application) you use the Win32 API's DeviceIOControl function to send messages to a driver, these messages can include callback addresses which enables a driver to communicate back with the userland process.

A userland program will do this:

  1. Call CreateFile to create a file-descriptor which represents the device
    • Ignore the fact it's called "File", this is one of the cases where Windows resembles Unix's "everything is a file"-philosophy.
    • Devices are typically under the namespace \\.\${deviceName} which compares with Unix's /dev/${id} namespace, for example. Note that each backslash needs to be escaped, so \\.\Foo becomes "\\\\.\\Foo" in C/C++.
    • File-descriptors in Windows are abstractions that represent many kinds of objects, you can see a listing of objects using the WinObj utility: https://technet.microsoft.com/en-us/sysinternals/winobj.aspx
  2. Call DeviceIoControl (passing in the file-descriptor from step 1).
    • The other parameters in the DeviceIoControl are defined by the driver or the driver's "device class" - not knowing more about your driver I cannot provide further assistance.
  3. Don't forget to call CloseHandle afterwards.
    • Be sure to call it in exceptional circumstances too (e.g. in a finally block in C# or wrap all access in an IDisposable implementation). As you're dealing with a third-party driver of unknown provenance I don't know how reliably it will handle an unpredictable userland process. Certainly this is how userland programs can crash an entire system: by triggering bugs in kernel-mode drivers via DeviceIoControl.

Depending on the device, your userland program may need to run as an elevated process (with administrative rights) in order for DeviceIoControl calls to succeed.

This page on MSDN details how you can use DeviceIoControl to communicate with a driver: https://msdn.microsoft.com/en-us/library/windows/desktop/aa363147(v=vs.85).aspx however specific argument values will need to be be gleaned from your driver's documentation.

Upvotes: 4

Related Questions