Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.More Info on Driver Writing and Debugging
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Driver Development- Found Legacy Operation "LogConfig" and "FactDef"
Tamilselvan
Member Posts: 6
I have been developing ISA device driver for Windows 10.
I had been using the "LogConfig" directive to specify the driver's resource listing, but Microsoft has deprecated it. I have been actively exploring alternative methods to address this problem. During my search, I came across a conversation related to this specific issue.[https://community.osr.com/discussion/293327/coming-back-to-driver-development/p2]. I attempted to utilize the "FactDef" method instead of the LogConfig in the inf file. However, this approach yielded the same error message of "Found legacy operation FactDef."
Since these section has also been deprecated by Microsoft, I am currently in search of an alternative method to address this situation.
I would greatly appreciate it if someone could provide input on this matter.
Howdy, Stranger!
| Upcoming OSR Seminars | ||
|---|---|---|
| OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
| Kernel Debugging | 16-20 October 2023 | Live, Online |
| Developing Minifilters | 13-17 November 2023 | Live, Online |
| Internals & Software Drivers | 4-8 Dec 2023 | Live, Online |
| Writing WDF Drivers | 10-14 July 2023 | Live, Online |
Comments
So the docpage for factDef claims (or rather implies) that it remains supported for manually installed device drivers. It would be nice if they explained exactly what they mean by that and how your manually installed driver non-package differs from a manually installed driver package. In this thread here https://community.osr.com/discussion/293940/inf-file-for-legacy-isa-driver-error-submitting-to-microsoft#latest it isn't clear if this was a failed attempt at WHQL signing or Attestation signing. If you can't get it attestation signed then that's the end of the story: it won't install other than in test signing mode.
I"m the one who started the other thread you commented on, and yes I'm stuck in Microsoft hell about it. Since I last looked at the page on FactDef they added a caution
Since my partner is a lawyer she's taught me a lot about parsing rules. I would think from reading this that a universal driver is a subset of a Windows Driver, but it appears Microsoft describes a "Windows Driver" and a "Windows Desktop Driver" as two different things, and maybe a Windows Desktop Driver can use FactDef to specify resources in the INF. Maybe.
It would be nice if they specified where FactDef could be used rather than where it can't be used using language that isn't very precise.
If it can only be used in a Windows Desktop Driver, then how to you specify in the INF file that it's a desktop driver? I can't find any information on that at all. Googling
"Microsoft desktop driver" INF
Doesn't yield anything useful.
I was able to install the driver with the settings to test drivers disabling the certification requirements. I had a lot of headaches getting the Azure account set up to upload a signed driver for Microsoft counter signing, but it was rejected because of the FactDef in the INF file.
Anybody know how to designate an INF file to be for a Microsoft Desktop Driver"?
Thanks for this discussion, I see the confusion here and will try to clarify this in the docs going forward.
There are two different aspects to this that are getting crossed - what will work functionally, and what will get a WHQL signature. FactDef and LogConfig are both deprecated, however the code that handles those directives is still present on desktop (this will not change). MS will no longer be providing a WHQL signature on INF files using deprecated directives, though.
So, yet another class of devices is forced back into attestation signing.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
Thanks for the update.
Actually I am having ISA device, if LogConfig and FactDef it deprecated what is the alternate way to provide IRQ to driver.
Can you suggest some other method to Pass the IRQ to driver instead passing through INF file.
There is no alternative. You have to use those statements. You simply can't get WHQL, end of story. NO ONE is going to be doing any new development for 40-year-old technology.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
I was under the impression they cannot even self attest sign.
I was trying to do an attestation signing, but from what I understood you still needed to submit it to Microsoft to go though attestation signing. I'm I missing something?
I contacted Microsoft tech support and kept getting the run around. In my last exchange I asked the question directly if non-PnP hardware is no longer supported. So far the answer has been crickets. That was two days ago.
I've been talking to my customer and they are looking at the possibility of changing the hardware to include PnP circuitry. That may be the only way to get a 64 bit driver into their customers hands. We've been using a 32 bit driver, but many customers want a 64 bit driver because their corporate policies are pushing for all computers to be running a 64 bit OS. Corporate policies have also not been happy with a non-signed driver either.
Sure you can. There are no mandatory tests that must be passed for attestation signing.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
I don't think you are missing anything. A while ago, the Microsoft Hardware Dashboard has been accepting my self attested driver submissions no problem and then one day it suddenly stopped accepting them and complained about the INF file. Luckily for us this was a simple adjust to the INF to get the dashboard to accept and sign them (our driver is PnP).
yes, attestation signing requires a valid inf if you are signing a pnp 'driver package'. You can get non pnp drivers attestation signed, I wonder if there is an approach there where you get your driver .sys file signed and then manually install it. The end goal is to get the stupid thing installed, not to pass the whql/attestation inf tests.
There is an acceptance criteria for attestation signatures as of December, and any deprecated directives will not be accepted.
In the absence of a definitive answer from Microsoft regarding their dashboard not accepting non-PnP drivers in any form, this would be my long term approach.
Short term I would look at a microcontroller and off the shelf USB to serial cable if, as indicated, your data rates are slow enough.
You have an answer from Mr. Lockard, which is about as definitive as you can hope to get: "There is an acceptance criteria for attestation signatures as of December, and any deprecated directives will not be accepted."
If Mr. Lockard said it, in this context, you can take it to the bank.
So... there's the official policy.
Peter
Peter Viscarola
OSR
@OSRDrivers
I fully accept that and agree.
Unfortunately I have managers who want unequivocal answers from Microsoft. I was thinking from that perspective. Luckily we have an OEM distributor for Microsoft product with a lot of clout. And we buy a lot of Microsoft product from them. So we tend to get those answers.
Great point, I'll update the INF documentation shortly to show this syntax as blocking. I also realized that we had labeled some (other) syntax as deprecated which is not yet blocking anything, so these updates will clarify the current status.
Thank you Zac for trying to help.
The data rate is dead slow, however, the way the ISA interface works, it sends or receives only one byte at a time, and they did not implement an interrupt line when they built the hardware, so when the external hardware is doing an A to D conversion, the OS sits there and polls the interface.
They had tried a USB solution that just converted all the calls to the ISA to USB and the interface got slower than molasses in January. I dug into it and found that it was the way the USB protocol was set up. The USB controller gives each hardware device a sub-frame of 125 us to transfer all it can every 1 ms frame. With one byte per transfer, this slows down the transfer rate to 1 byte per ms.
I found some areas where I could pack up multiple bytes into one packet and speed things up some and wrote microcontroller code to unpack it on the external hardware end, but there were times when we would be stuck with one byte per ms. I got the hardware and code to the test phase, ran into some problems (I think processes were stepping on each other) and ran out of time to debug it. That was 10 years ago and they haven't cut me loose to go back to it since. Someone else took it up a couple of years ago, but he didn't understand the problem with the frames and sub-frames and didn't want to listen to me so his efforts failed. He's no longer with the company.
The company is very hardware oriented. I'm am the entire software department. Even though I have a degree in Electronic Engineering they don't seem to want me to get too close to the hardware so the USB project has just sat on the shelf for a decade.
The guy I work with the most would like to do a USB interface, but his management is the roadblock.
After reading the rules (I do not work for FTDI) may I suggest
https://ftdichip.com/
They do USB to serial (UART) converters in chip and cable form. They have their own drivers.
As long you know how a UART works this could be your 'plug and play' interface. Add this to a microcontroller and you may have a solution.
Yes, I admit my knowledge was out of date. I have to say it surprises me greatly that there are now classes of devices that can no longer be used on Windows. More impetus to move to Linux, I guess.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
INF directives/sections that will block signing are now tagged as such in the docs, such as https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-logconfig-directive
I'm entirely in your camp on this one, Mr. Roberts.
In fact, it does more than surprise me greatly. I find it foolish, short-sighted, and perhaps even slightly professionally offensive. Apparently our colleagues in Redmond don't know, or don't care, that there are still lots and lots of industrial automation and factory floor devices that are ISA-based. I guess the attitude is: Redesign it as a PCIe device, or forget about it.
However, I DO admit to now being used to this type and level of offense when it comes to driver signing. I got used to it when MSFT made it impossible to sign a Windows 7, Windows 8, or Windows 8.1 driver that did not pass the logo tests. Try as I might, and I tried mightily, I could not get a single, solitary, person that I spoke with at MSFT to understand (or perhaps care) that there are legitimate categories of devices that will never be logo-able under any circumstances.
It has become very clear that MSFT does not care, even a little bit, about process control or embedded systems.
Never mind... I am merely railing against the tide.
Love having you here, Mr. Lockard. No offense. But what you've explained to us is outright bad policy.
Peter Viscarola
OSR
@OSRDrivers
To be clear (in case it wasn't), all of these directives still work and will continue to work, you'll just have to sign it yourself and configure the system to accept your signature during driver install. I understand that's not ideal
I appreciate the feedback
Do you mean “enable test signing?” Or is there some other signing mechanism of which I’m unaware.
Real question, in case there’s any doubt. No sarcasm whatsoever implied.
Peter
Peter Viscarola
OSR
@OSRDrivers
Me, too. I was under the impression there we no longer ANY paths that enabled self-signed drivers, period.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
If there is some route other than "test signing" I would love to know. Using test signing will not pass most corporate IT requirements, so it's not viable for out in the field.
You are able to edit the pages on Microsoft's site? If so the caution is inaccurate from what I discovered. I tried to submit a driver with attestation signing for Win 10 only and it was bounced. Tech support told me that all drivers submitted not must pass infverif /k for Win 11 2H22, even if they are not targeted for Win 11.
That's about the only real information tech support told me. The rest of it was all run around.
Back when I was working on the USB project I found a combined interface and microcontroller from Cypress that did everything we needed. Using the I/O pins of the chip I was able to drive the backplane bus in the external chassis just fine.
At the time there were multiple apps that accessed the hardware at the same time. These were written in the late 80s originally for Windows 1.0. Most of my work the last few years has been writing a multifunction app that replaces the multiple apps. I could get the hardware to work just fine with USB with one app running. When I tried with the multi-app suite I ran into problems. My assumption is that there was some sort of race problem going on and the FIFO on the controller was getting out of sync.
I have been campaigning to use a Raspberry Pi as the USB slave. It has a lot of advantages for debugging tools as well as future expansion. The systems engineer has some long term ideas about expanding the function of the microcontroller once its working.
In low volumes Raspberry PI is fine apparently.
Avoid Arduino as you will run into potential licensing problems (as per linux). GPL sucks.
As far as I know, you can add the certificate that signed the driver to the trusted root certification authorities store on local system and then that certificate will be accepted, without test signing enabled.
The requirement was enforced in the Win11 22H2 HLK, and if you submit a driver through attestation you have to meet the INF requirements of the latest HLK regardless of targeting