How to understand the internal working of NDIS Miniport driver - windows

I am new to Window driver development.
I am trying to understand the working of a NDIS miniport driver (from Microsoft WDK samples). Especially, to understand the packet flow.
As per numerous sources, I have seen suggestions of installing two instances of NDIS miniport driver and proceed from there. However, I am unable to continue from there, as there is only vague info. Please advise - Especially on how to attach a Windows Debugger Tool to an instance of the driver and to see the callbacks being called on sent/receive packets.
My platform: Windows 7 x64 with debug mode set (Debugging Setup: Single Computer).
There is a similar question. But no info about how to debug the driver: NDIS and miniport driver

You can't debug on the same machine in which you are running the driver, you need to use remote machine, that could be a "Real" one or as done usually a VirtualMachine.
Here how to setup a Windows Kernel Debugging environment with a Virtual Machine:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff538143%28v=vs.85%29.aspx

Best way to understand driver internals of driver is to use WPP tracing in driver to print messages and view using traceview.exe. Or using dbgprint() to print messages and these messages are viewed using dbgview.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff556204(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/ff543632(v=vs.85).aspx

Related

ETW (Event Tracing for Windows) Bluescreen

When I want to enable ETW tracing to receive driver events, I do such:
logman start "NT Kernel Logger" -p "Windows Kernel Trace" (driver) -o s.etl -ets
So on some machine, after running the above command, the computer crashes. After analyzing the memory dump, I figured out that the problem was caused by "TAOKernel64.sys" which is developed by a Chinese company named "Tencent". After removing a program which installed that driver (QQ PC Manager), the problem resolves.
I had two major questions:
1-
Does receiving driver events from ETW require all drivers to work properly? So can we have a buggy driver installed and enabled (but not used) and use ETW without causing BSOD? Or I had faced a completely different problem?
2-
Can we filter out some of these drivers in ETW (either real-time or offline)? For example, telling ETW not to collect driver events from that .sys file?

Installing NetSerivce NDIS Filter Driver on Windows IoT Core

I know that there is a simple driver example to install a device driver on IoT Core. I cannot find any information about how to install a NetService type NDIS filter driver on IoT Core. I have trouble installing a NDIS Filter Driver on IoT Core, which is quite different from a general device driver.
My NDIS filter driver is basically from VS2015 NDIS filter driver sample. I already successfully put it on a target Win 10 Enterprise PC and can see its trace messages via VS2015 Kernel debugger window from Development computer.
I was also trying to put it on Windows IoT Core, and my hardware is Minnowboard Max. My steps are:
Follow
https://ms-iot.github.io/content/en-US/win10/samples/DriverLab4.htm
to just set up the provisioning on the target IoT Core from VS2015
on dev computer.
Follow
https://channel9.msdn.com/Blogs/WinHEC/Creating-Universal-Drivers-with-WDK-10
to prepare for the mobile package (.cab file). Need to enter the
required info in Package.pkg.xml file. Build the x86 debug version.
Follow the same link as bullet 2 to deploy the .cab (online .cab package installation/update) on IoT
Core from VS2015.
However, after connected via Kernel Debugger and set Kd_DEFAULT_MASK
= 0xF, cannot see any filter driver’s trace messages.
“devcon listclass NetService” returns empty.
Can anyone give me any instructions or hint? (This issue
is only for IoT Core. I successfully made it work on Windows 10 Enterprise already.)
Unfortunately I don't think that NDIS LWFs can be installed onto Windows IoT Core currently. What's the high-level problem you're trying to solve? Maybe there's another way to solve this problem that doesn't involve LWFs.

Writing a windows class driver

I'm new to WDM driver development, but I have an experience developing
Linux drivers.
i want to develop Ethernet over USB class driver for windows XP. (CDC-ECM class driver)
i know that windows only support RNDIS/NDIS for the network class and thus i will need to write a custom windows driver that replace the RNDIS driver while maintaining the rest of the USB stack.
so far i downloaded the windows driver kit (WDK) and still reading the documentation.
does anyone know how to do this or where to get started ? (other than WDK documentation)
i tried google but still can't figure it out.
Regards,
You have to write a NDIS Miniport driver which uses a USB KMDF miniport driver at the lower edge.

How do I get to see DbgPrint output from my kernel-mode driver?

I'm finding it difficult to see the debug output from a kernel-mode driver I'm working on.
I'm new to driver development. I'm trying to debug a USB driver on Windows XP. I've installed the DDK, and built a "checked mode" build of my driver. I've installed the driver and if I use a hex editor to look at my driver's .sys file in windows/drivers, I can see the text of my debug output strings.
If I run an app that uses my driver under Visual Studio, my debug output doesn't appear in the output window, as the application's own debug output does. Searching the web, I find many different claims about how one is supposed to display debug output from the kernel. For kernel debugging in general, people seem to either do remote debugging over a NULL modem cable (Crikey, it's 2012) or use a virtual machine and a virtual com port. Both these approaches seem like a massive amount of work just to be able to see debug output. Is there an alternative?
I've tried using WinDbg in "Local" kernel debugging mode but it doesn't show anything. It warned that I should reboot windows with "/debug" enabled. I did that, but it didn't help.
Any other ideas? Or am I asking for the impossible?
DebugView will show you the trace messages from your driver:
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
However, you really do need a two machine setup to do any real development work.
The information you found is correct. You do need 2 machines to debug kernel-mode drivers.
If you choose to use 2 physical machines they can be connected via USB. NULL modem (COM port) is a common way to attach debugger to a virtual machine where VM's COM port is seen as a named pipe on the host, so you don't really need a NULL modem cable.
Couple of links
http://msdn.microsoft.com/en-us/library/ff538141.aspx
http://msdn.microsoft.com/en-us/library/ff542279.aspx

NDIS Miniport driver failed to load on XP OS during a particular scenario

Our USB composite device will support different functionality.one interface will support Network functionality.
We are developing different NDIS miniport versions for different OS.(NDIS 5.1 for XP, NDIS 6.1 for Vista and NDIS 6.20 for Windows7 OS).
We have one test case as shown below:
1) After loading all drivers(serial and NDIS) open any serial interface using Hyperterminal
2) Do Some communication (enter AT command etc)
3) Unplug the device with out closing Hyper terminal
4) Replug the device to the same USB port.
For the above test scenario, NDIS miniport driver fails to load after step-4(error code 31) on XP OS.NDIS Miniport drivers' Initialize handler is not called.
On other OS i am not able to reproduce this issue.
Please let me know your valuable suggestions for this issue.
It's possible you're not releasing all of the resources you hold upon unlpug. Check your unplug handler code.

Resources