inf file creates Unknown device in Device Manager

Applying the package to an existing device is accomplished through devcon update. You don’t have to force a reenumeration in your installer, use DiInstallDriver and friends instead.

1 Like

pnputil /add_driver /install can perform this function as well.

@Tim_Roberts Thanks, your method works. I do not see Unknown device anymore.
@craig_howard and @Doron_Holan , I am not familiar with writing these instructions so I am looking for some command line methods to trigger a driver start. Reboot takes too long on my test machine.

Still, is there something wrong with my changes to inf file that causes 2 devices to be detected?

Neo

devcon.exe disable
devcon.exe enable

Or

pnputil /disable-device /device-id
pnputil /enable-device /device-id

Or just use Device Manager (devmgmt.msc) to disable and then enable the device.

@Tim_Roberts said:
pnputil /add_driver /install can perform this function as well.

Umm … the /install option isn’t on the pnputil on my Win10 boxes, and isn’t in the doc’s [ https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/pnputil-command-syntax ] … when was the last time you ran that exact command?

Devcon update, pnputil /disable-device, pnputil /enable-device, devcon disable, devcon enable all depend upon the PnP target already being in the PnP stack … which is not what the OP is attempting to accomplish

The OP has a Win10 machine which has a PCIe device in it, and which is (likely, unless he’s using a Thunderbolt chassis) showing as “Unknown PCI device” in Device Manager. The OP has a driver which can talk to that “Unknown PCI device”, now he needs to have the OS make the connection without user intervention (so calling devmgmt.msc won’t work) and without doing a reboot.

As I understand it (and I could easily be wrong here) an object in Device Manager showing “Unknown PCI device” isn’t a part of the PnP stack, so there’s nothing to /enable or /disable and it doesn’t really “exist” to the OS. DiInstallDriver (and friends) have as a last step “reboot required” [ https://docs.microsoft.com/en-us/windows-hardware/drivers/install/functions-that-simplify-driver-installation ]

In my experience, installing the driver into the driver store is easy (and there are a plethora of functions to do that), it’s making the jump from “Unknown PCI device” or “Unknown USB device” to the OS loading up that driver and using it without forcing a reboot is the tricky thing, and calling a full renumeration has always worked out well for PnP devices and with some file system filter drivers as well …

Unknown PCI device Showing up in device manager means it is a pnp device. It has a hardware id and can have a driver installed against it. Devcon update and all the other pnp driver install tools listed most definitely work in this scenario.

1 Like

@craig_howard and @Doron_Holan , Thanks for your input. I think I have found a solution.
Whenever I want to test changes to driver design, I use Device Manager → Uninstall device → Delete the driver software for this device. Then the device disappears from Device Manager tree. Then I run Device Manager → Scan for hardware changes and the device re-appears in Device Manager as Others → PCI Serial Port. It will not have drivers installed.

Previously I would run in cmd

devcon install avshws.inf PCI\VEN_10ee&DEV_9024

but this will create an extra Unknown device with no drivers as reported previously.

The solution is to right click on PCI Serial Port → update drivers. This way, Unknown device will not be created.

Umm … the /install option isn’t on the pnputil on my Win10 boxes, and isn’t in the doc’s

It absolutely is. in the second gray box on that page. It’s a sub-option with /add-driver.

@Doron_Holan said:
Unknown PCI device Showing up in device manager means it is a pnp device. It has a hardware id and can have a driver installed against it. Devcon update and all the other pnp driver install tools listed most definitely work in this scenario.

Hmm … so I tried an experiment; I use a Galatea Tagus [ https://numato.com/product/tagus-artix-7-pci-express-development-board/ ] board for FPGA development, and connect it to the PC using a Thunderbolt3 expansion chassis [ https://www.startech.com/en-us/cards-adapters/tb31pciex16 ] using an Asus Alaska class motherboard [ https://www.asus.com/us/Motherboards-Components/Motherboards/Workstation/Pro-WS-W480-ACE/ ] which supports Thunderbolt3. OS is Win10 21H2, Thunderbolt full access was granted in the BIOS

To test the Thunderbolt connection I used a standard PCIe serial card [ https://www.amazon.com/StarTech-com-PCI-Express-Serial-Card/dp/B01N25W4P9 ] which worked as expected; plug the PCIe card into the TB3 chassis, plug in the TB3 connector into the motherboard, Win10 detected the serial card and loaded the stock driver and poof I have two serial ports

I then loaded some PCIe 2.0 IP into the Artix on the Tagus, unplugged the TB3 chassis and replaced the serial card with the Tagus, repowered and replugged the TB3 connection; the PnP stack renumerated upon the TB3 insertion, removed the serial card and detected the Tagus; however, as it has no idea how to interact with the card it placed it in the “Unknown PCI device” section. When I look at the properties of the card I can see a bus and function number but that’s it … again, as expected

I then disconnected the TB3 chassis, powered it down and loaded up a very simple PCIe Firmware image into the Tagus which supports one 4MB BAR, two MSI-X interrupts and one DMA engine with my own VID/ PID and again repowered and replugged … the PnP bus renumerated on TB3 insertion, still placed the card in the “Unknown PCI device” section but now shows the VID/ PID of the card (so I know it’s able to read the ECAM space)

I then took a KMDF PCIe driver which interacts with the Firmware, and attempted the following experiments. To ensure that I wasn’t polluting the universe before the experiment I made an RDriveImage copy of the OS and restored from that copy before each of these experiments, and examined the results of the setup.dev log file in \inf, SecureBoot was off and TestSigning enabled, code Authentication disabled …

pnputil /enable-device /device-id … installs in driver store, sits there quietly, Numato still shows as “Unknown PCI device”, driver failed to start
pnputil /add-device … same as /enable-device, driver failed to load
devcon update … same as pnp-util, driver failed to load

I then ran my Wix custom action DLL for this type of driver which uses the DiXX functions but had the forced renumeration portion commented out and again, in the driver store but still the driver stubbornly failed to load

Finally I uncommented the forced renumeration portion of the custom action DLL, the driver went into the driver store and still failed to load BUT when the forced renumeration occurred the driver was successfully started and PrepareHardware happily showed me a BAR and two MSI-X interrupts, and my scatter/ gather DMA started chugging along …

Thoughts? I would be so totally glad to be able to avoid this dance step, but I can’t afford to reboot the machine on driver installation when a new card is installed …

@Tim_Roberts said:

Umm … the /install option isn’t on the pnputil on my Win10 boxes, and isn’t in the doc’s

It absolutely is. in the second gray box on that page. It’s a sub-option with /add-driver.

Yep, quite correct, totally whiffed on that one! Thx! :slight_smile:

Hmmm… first Mr. @craig_howard your post isn’t in answer to the OP’s question. So, thread hijack.

Next…. What’s the goal? If you just want to load the driver without rebooting, go into device manager right click the device, select update driver, and be done with it.

Peter

@“Peter_Viscarola_(OSR)” said:
Hmmm… first Mr. @craig_howard your post isn’t in answer to the OP’s question. So, thread hijack.

Sorry, things drifted onto a topic which has always bothered me, how to install PCIe driver(s) without a reboot. Probably should have created a new thread rather than taken the segue …

Next…. What’s the goal? If you just want to load the driver without rebooting, go into device manager right click the device, select update driver, and be done with it.

That works good for manual installation by a knowledgeable user, not so much for end users who just want to double click on a single MSI and be done with it (and who actually have device manager locked down by policy). I’ve tried a number of approaches, so far the “best” is force a renumeration once the driver store has been loaded up … was hoping to find a better way, that was the goal

Segue abandoned …

So, the question is: “How do I programmatically get a driver loaded for a device that’s already attached to the system”…

That should certainly be solvable. I don’t know HOW myself (I know very close to nothing about installation, never having to deal with it). But, it’s GOTTA be solvable, right?

Peter

@“Peter_Viscarola_(OSR)” said:
So, the question is: “How do I programmatically get a driver loaded for a device that’s already attached to the system”…

That should certainly be solvable. I don’t know HOW myself (I know very close to nothing about installation, never having to deal with it). But, it’s GOTTA be solvable, right?

Peter

Not quite … a better question would be “How do I programmatically get a driver started for a driver already in the driver store for a PCIe device already attached to the system but not recognized” … load the driver is easy, many ways to do that, and most of them are already in this thread. I have a feeling, however, based on the answers that most people then say “… and reboot” but for medical devices, high availability datacenters (like bladeservers) and factory floors that is simply not an option.

A common (for me) scenario is for industrial equipment to be tightly coupled/ cabled to a PCIe control card … and with new actuators, new sensors, etc there needs to be a new FPGA core to drive all that and (usually) a new PCIe card to go with it. That new PCIe card, of course, needs a new driver … so all the customer wants to be able to do is once the new card/ equipment/ driver has been tested power down the old card, drop in the new card, power it up and doubleclick an MSI application that magically installs the new stuff and everything just “works”. No interruption on the line, no glitch on the MRI machine, no taking a datacenter down, just put on the new tires while the engine is running and done

In the “old days” I accomplished that with a Compaq SystemPro with PCIe buses which could be powered on and off (con: very expensive, no longer made), later I used interposer riser cards with circuitry to maintain the PCIe bus (con: won’t fit into a normal case, require the user to physically flip a switch twice at just the right times), these days I use a ThunderBolt3 external chassis (con: needs newer motherboards that still need to be married to specific expansion chassis) that is very simple for the end user; unplug the TB3 cord, swap cards, replug the TB3 cord, done.

The tricky part is in getting the PCIe device to load the new driver without needing a reboot, and that’s where everyone seems to be playing the “assume” card. The only way I’ve found is to programatically force a rescan of the PnP stack, which is similar to using a DaisyCutter FAE [ https://en.wikipedia.org/wiki/BLU-82 ] to clear some brush around your house …

And since it’s clear that posting that question to a new thread will simply elicit a storm of “use devcon” or “use pnputil” or “click on the device manager node and hit ‘update’” answers I’ll stop now before you lob grumpy-grams my way … :slight_smile:

So, device and no driver showing in Device Manager?

Well, hmmmm… isn’t that what DevCon Update does?? And the source code for DevCon is available, and licensed for reuse?

Peter

Thanks for your attention to this post. I did managed to prevent Unknown Device from being installed by using Device Manager → Update Drivers. However I still don’t know if my INF file has errors. Or the problem is caused by devcon.

However I still don’t know if my INF file has errors.

So what do you still see that looks wrong? Do you work on a clean system, or registry and driver store are polluted by previous experiments?

@craig_howard said:
a better question would be “How do I programmatically get a driver started for a driver already in the driver store for a PCIe device already attached to the system but not recognized”

To start a driver it must be installed on the device first. Driver already in the store does not mean it is installed.
To complete the PnP install ceremony, the bus driver MUST recognize the device and make various IDs that match the driver.
No matter how many drivers you put in the store, if the bus driver cannot enumerate it - the game is over.

but for medical devices, high availability datacenters (like bladeservers) and factory floors that is simply not an option.

A lot of systems have hot plug PCIe and even legacy PCI. PCIe has special provision for hot plug … the rest is software.

No interruption on the line, no glitch on the MRI machine, no taking a datacenter down, just put on the new tires while the engine is running and done

Yes, exactly this way.

The tricky part is in getting the PCIe device to load the new driver without needing a reboot, and that’s where everyone seems to be playing the “assume” card.

Really? the tricky part is proper handling of surprise removal. Especially, usermode apps must not hold on any handle that pins down the surprise-removed instance so that it can be restarted quickly.

Not mentioning what if the hardware or firmware cuts some corners of the spec because the other OS can tolerate it… Windows is not too bad after all.

1 Like

@Pavel_A When I use devcon to install drivers, I still get Unknown device besides the correct device. So I am not sure if the problem is due to devcon or my inf file. You can refer to my reports above how to avoid having Unknown device created.

I am sure I have remove previous copies of drivers as Windows 10 does not automatically install them when I perform Scan for Hardware changes. Everytime I uninstall device I always check “Remove driver”, and

dism /online /get-drivers /format:table
pnputil.exe /d oemNN.inf

When I use devcon to install drivers, I still get Unknown device besides the correct device

Do you mean you use devcon install? If so, then that’s exactly what you are asking for. If you want to stop that side effect, then for gosh sakes STOP USING devcon install. It was NEVER intended to work with drivers for genuine devices.