netvmini sample

I’ve gotten the netvmini sample driver built and deployed to my Target PC x64.
I see the NetVMini680.sys file has been copied to System32\DriverStore\FileRepository\netvmini680_amd64_xyz1234
But I’m not sure what to do to test it.
The docs say to instantiate two instances of the driver and use the sample program to communicate between them.
But the sample program is missing. I’d like to build one but don’t know where to start.
I don’t see any references to the driver under Device Manager, Network Adapters. And I don’t see the driver listed in msinfo32, Software Environment, System Drivers.
Any help appreciated, sorry for my complete lack of driver experience.

There isn’t a test app anymore. The NDIS 5 version of netvmini had a little GUI program that gave you a button to add & remove adapter instances, but it wasn’t actually super useful. You can do the same with devcon install c:\path\to\netvmini.inf root\NetVMini680_a, or by clicking around in devmgmt.msc.

netvmini creates an Ethernet hub in-memory. All netvmini instances are automatically plugged into this hub. So once you have 2+ instances of the device, they will see traffic from each other. You can test it by assigning static IP addresses to each netvmini instance, hacking up the route table, then sending traffic back and forth.

Regarding route table hacking: TCPIP has an optimization whereby if you send traffic to any locally-assigned IP address, TCPIP just moves the traffic directly there, without bothering to go down to NDIS. This is normally a good thing. But if you’re testing an NDIS driver, you probably wanted to see the traffic. You can defeat TCPIP’s optimization by editing its routing table to delete the entry that corresponds to your IP address. For example, if you assigned 192.168.5.1 to a netvmini interface, run route.exe delete 192.168.5.1.

If hacking the routing table doesn’t sound fun, you can alternatively force traffic to go through the interface by creating a Hyper-V VM, and binding its external vswitch to one of the netvminis. Now you have 2 separate TCPIP stacks (one in the host, one in the guest), so they can’t conspire to take any shortcuts; they’ll be forced to send traffic all the way down to NDIS.

2 Likes

When I use devcon to add a netvmini root device as follows:
devcon install netvmini680.inf root\NetVMini680_a

Device manager shows the device install failed - it’s icon has a caution icon overlay.
When I right click the device and choose properties the device status is:
Windows cannot initialize the device driver for this hardware. (Code 37)
{Operation Failed} The requested operation was unsuccessful.

I have a TraceView session open with netvmini680.pdb and it shows these log statements:

00000037 680 4 3124 3 37 09\11\2020-12:45:23:850
—> DriverEntry built on at
00000038 680 4 3124 3 38 09\11\2020-12:45:23:850
Calling NdisMRegisterMiniportDriver…
00000039 680 4 3124 3 39 09\11\2020-12:45:23:850
NdisMRegisterMiniportDriver failed: -1073676283
00000040 680 4 3124 3 40 09\11\2020-12:45:23:850
—> DriverUnload

I attached a screenshot of the target machine showing Device Manager, the DOS window devcon command, TraceView session and registry hive.

Not sure why but the single devcon install command is creating two instances of the device.

Also the RegistryPath that gets passed into DriverEntry is “vv” ?? I added a DEBUGP statement to show that in the Trace. No idea how that’s happening.

Any help appreciated.

#define NDIS_STATUS_BAD_CHARACTERISTICS ((NDIS_STATUS)0xC0010005L)

Do you have a [DeviceInstall32] section? If so, the system will create a devnode for you automatically in addition to the one “devcon install” creates. You might consider using pnputil instead.

1 Like

Thank you Tim_Roberts.
I’m using the sample program’s netvmini680.inf in stock form as downloaded from github.

It has these sections for all configurations. The one I’m targetting is NTamd64:

[Manufacturer]
%ManufacturerName% = Standard,NTx86,NTia64,NTamd64,NTarm,NTarm64

[Standard.NTamd64]
%NetVMini.DeviceDesc% = NetVMini.ndi, root\NetVMini680_a ; Root enumerated
%NetVMini.DeviceDesc% = NetVMini.ndi, root\NetVMini680_b
%NetVMini.DeviceDesc% = NetVMini.ndi, root\NetVMini680_c
%NetVMini.DeviceDesc% = NetVMini.ndi, root\NetVMini680_d
%NetVMini.DeviceDesc% = NetVMini.ndi, {b85b7c50-6a01-11d2-b841-00c04fad5171}\NetVMini680 ; Toaster Bus enumerated

I can install the netvmini60.inf and netvmini630.inf devices without error.

Not sure why but the single devcon install command is creating two instances of the device.

I doubt this is happening. Rather, what probably happened is that you called devcon install twice and if I were to guess, the first invocation created the device node but failed to start and you retried the command. You only need to call devcon install once to get the devnode created. After you have a devnode, call devcon update to install a new driver package on the existing root device node. %windir%\setupapi.dev.log will tell you exactly when/why the two dev nodes were created (you can search with the string of the device instance path of each instance to quickly find the entries). If you only want one virtual device, just go to device manager and delete the unwanted second.

True - it only installs one device. Must have been user error.