I’ve got a set of drivers for non-PnP devices. The I/O Port ranges, memory ranges, and IRQs in the devices are hard wired and not configurable. These devices are part of an embedded system.
I can successfully provide all the necessary resources using LogConfig in the INF file. And I can install the device just fine (for example using DevCon for in-house testing).
The only issue I’m having is that the drivers initially come up yellow banged In Device Manager. Specifically, after installing each driver, I have to manually select (the only available) device property set in Device Manager and reboot the system.
Does anybody know if there’s a way to avoid having to manually make the resource selection and reboot?
Like I said the INF contains one set of resources… Indicated as “hardwired”…
This may not be directly be answering the question, but do you own/control the system? If so, you could try adding an ACPI device entry for the device, and describing the resources there with _CRS.
This should avoid the .inf/LogConf needs, and should get rid of the yellow-bang.
Out of curiosity, what does the devnode state history show (!devnode)?
That is a VERY creative idea, Alex. It made me smile this morning. Thanks.
Sadly, it’s not practical in this case for a variety of reasons. The client buys the computer from an IHV and “integrates it.” This means they take the SSD that has Windows Embedded on it, that they buy from another IHV, plug it into the computer, plug a few devices into the ISA and PCI buses, attach some wires, and stick the whole thing in a closet-sized chassis.
AND… they need to support Windows XP Embedded and later. No, seriously.
All together, this would be a relatively complex solution and the client’s engineers are really specialists in their field and in their instrument, not in Windows OS stuff. This is where we come in. We could probably make it so that they don’t need to deal with the complexity inherent in a “roll your own DSDT” type solution, but they also have different hardware configurations per customer (apparently based on… I have no idea what they’re based on, really). So, sometimes the IOPORT range will start at 310, sometimes at 220 (for example).
So… Great, fun, idea. Like I said, very clever and very creative (I’m disappointed I didn’t think of it myself! I love at least thinking about “shoot a fly with an elephant gun” type solutions). But unfortunately not workable in this case.
Sigh! You’d think the installer would be sufficiently clever to select the ONLY Property Set I provide automatically.
>I’ve got a set of drivers for non-PnP devices. The I/O Port ranges, memory ranges, and IRQs in the devices are hard wired and not configurable. These devices are part of an embedded system. > >I can successfully provide all the necessary resources using LogConfig in the INF file. And I can install the device just fine (for example using DevCon for in-house testing). > >The only issue I’m having is that the drivers initially come up yellow banged In Device Manager. Specifically, after installing each driver, I have to manually select (the only available) device property set in Device Manager and reboot the system. > >Does anybody know if there’s a way to avoid having to manually make the resource selection and reboot? > >Like I said the INF contains one set of resources… Indicated as “hardwired”… > >Peter >OSR >@OSRDrivers > > >— >NTDEV is sponsored by OSR > >Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev > >OSR is HIRING!! See http://www.osr.com/careers > >For our schedule of WDF, WDM, debugging and other seminars visit: >http://www.osr.com/seminars > >To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Just to close the loop on this: Mr Bottoroff’s recommendation WORKED! Thank you!!!
The client was happy for 2 minutes. Now they want to know how to suppress the dialog box that pops up and asks “Do you trust the driver written by XYZ Company”
You can please everyone. But I’m happy with Mr Bottorff’s solution, and that’s what matters to meet.