Driver Development- Found Legacy Operation "LogConfig" and "FactDef"

rob18767 · July 19

@Zac_Lockard said:
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

>

So if IoT core is to replace CE.... I guess we will meet that challenge when we come to it.

Is using Windows 10 IoT Enterprise LTSC 2021 a solution?

https://learn.microsoft.com/en-us/lifecycle/products/windows-10-iot-enterprise-ltsc-2021

Xiaofan_Chen · July 19

@Mark_Roddy said:
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.

I believe that is the way to go and it works, at least for Windows 10/11 x86/x64 (may not work under Windows 11 on ARM64).

We do that for libusb-win32 kernel driver (libusb0.sys). The .sys driver got signed with attestation signing with a proper inf file with one valid VID/PID. Then the end user (of course with different VID/PID) can use Zadig or libusbK-inf-wizard (both are based on libwdi) to install the driver.

libwdi:
https://github.com/pbatard/libwdi/wiki/FAQ#what-are-these-usbvid_pid_mi_-autogenerated-certificates-that-libwdi-installs-in-the-trusted-certificate-stores

Somehow this mechanism does not work under Windows 11 on ARM64.
https://github.com/pbatard/libwdi/issues/289

Xiaofan_Chen · July 19

@Zac_Lockard said:
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.

Just wondering if you know if this works under Windows 11 on ARM64. Thanks.

Reference discussion: libwdi/Zadig does not work under Windows 11 on ARM64.
https://github.com/pbatard/libwdi/issues/289

Peter_Viscarola_(OSR) · July 19

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.

Thank you for taking the time to reply, Mr. Lockard.

If that worked, there would be MUCH rejoicing in the driver development world. Consider all the military, medical, and process control drivers in the world where we could use this feature. I might even stop being cranky about the whole driver signing topic, if this were so.

Sadly, I have not seen it work in the past, and using Win11 22H2, I was not able to make this work:

:-(

To make this work, I've always had to enable Test Signing.

I would be very, very, happy to hear that I'm doing something wrong.

Thanks again,

Peter

I see in my snip I covered up the actual install status line. It reads:

!!! dvi: Device not started: Device has problem: 0x34 (CM_PROB_UNSIGNED_DRIVER), problem status: 0xc0000428.

Phil_Barila · July 19

That looks like the personal context. Is there a machine context as well?

Peter_Viscarola_(OSR) · July 19

That looks like the personal context. Is there a machine context as well?

Thank you, Mr. Barila... Rookie mistake, posting the personal context instead of the machine context!

Heres's the machine context (the cert is THERE as well):

Mark_Roddy · July 19

Installing your cert in trusted* was the documented and supported "release signed driver" method. That died when microsoft deprecated cross signed certs. Your driver can still be installed this way if and only if you signed it before the deprecation. Unless something changed in redmond, this path no longer exists. I'd be happy to be wrong.

rob18767 · July 20

Okay I will try again.

@Peter_Viscarola_(OSR) said:
Sadly, I have not seen it work in the past, and using Win11 22H2, I was not able to make this work:

Okay it does not work with Win 11 22H2

@Peter_Viscarola_(OSR) said:
Consider all the military, medical, and process control drivers in the world

Yes we do process control. The last thing you want with process control is for the drivers to stop working after an update right? Just like a large sign in kiosk mode beside a freeway.

Hence Microsoft developed Windows 10/11 IoT Enterprise LTSC. IoT being the new buzzword for embedded systems connected to the internet (We used to use Windows XP and 7 embedded). LTSC meaning 'Long Term Service Channel' in that any updates will not stop drivers from working.

(Also Windows IoT has cheaper licenses. I also see Windows IoT core is replacing Windows CE so you can expect some SBC devs over here).

So we do drivers for Windows 10 IoT Enterprise LTSC 2019

https://learn.microsoft.com/en-us/windows/iot/iot-enterprise/whats-new/windows-iot-enterprise-ltsc

Which is available until 2029 as version '17763' (1809). This is what I develop with at work for now.

(Windows 10 IoT Enterprise LTSC 2021 is available until 2032!).

Can non-PnP drivers be signed and uploaded to the dashboard for these versions of Windows?

Xiaofan_Chen · July 20

@Peter_Viscarola_(OSR) said:

>

To make this work, I've always had to enable Test Signing.

I would be very, very, happy to hear that I'm doing something wrong.

Thanks again,

Peter

As per my experience, as long as the .sys driver is Attestation signed, then you can create the driver package and use this method to install the driver package.

libwdi is using this method (it is just adding the on-the-fly generation of the certificate part).
https://github.com/pbatard/libwdi/wiki/FAQ#user-content-What_are_these_USBVID_PID_MI__Autogenerated_certificates_that_libwdi_installs_in_the_Trusted_certificate_stores

Catches: it does not seem to work under Windows 11 on ARM64.

Xiaofan_Chen · July 20

This is my thought for the OP to sort out the issue.

1) Prepare a driver package. The inf should follow the Windows requirement without the legacy "LogConfig" and "FactDef" directive.
2) Sign the driver package with Attestation. We only need the signed .sys file.
3) Throw away the cat file, and modify the inf file to include the legacy "LogConfig" and "FactDef" directive.
4) Use the method mentioned above to install the driver package.

rob18767 · July 20

My view is if a driver can be signed under a Windows 10 IoT Enterprise LTSC version then use that version of Windows for now at least.

MBond2 · July 20

Peter, can you show the details of the certificate that you used? In my experience, certificates in the trusted root need to have specific key usage and hierarchy requirements or they are ignored by the system.

Tim_Roberts · July 20

@Xiaofan_Chen, your plan works only as long as the INF is not a PnP INF. If the INF file is PnP, then the CAT file is required, and you can't modify the INF.

rob18767 · July 20

@Tim_Roberts said:
@Xiaofan_Chen, your plan works only as long as the INF is not a PnP INF. If the INF file is PnP, then the CAT file is required, and you can't modify the INF.

So is there a reason that Windows IoT LTSC could not solve this problem?

Tim_Roberts · July 20

I don't see what you're getting at. IoT has the same driver loading processes as desktop WIndows.

rob18767 · July 20

I never said it did not have the same loading experience.

Do non-PnP signed Windows drivers get accepted for pre 2022 versions of Windows in the Hardware dashboard?

Xiaofan_Chen · July 20

@Tim_Roberts said:
@Xiaofan_Chen, your plan works only as long as the INF is not a PnP INF. If the INF file is PnP, then the CAT file is required, and you can't modify the INF.

As I mentioned, you will need to throw away the inf and cat file. Only the signed .sys file is needed. Then you regenerate the inf and cat file. You can try it by using the following utility as part of libusbK project (which uses libwdi).

https://github.com/mcuee/libusbk/tree/master/libusbK/src/dpscat

Tim_Roberts · July 20

If it is a PnP INF file, then the CAT file has to be signed. The SYS isn't enough.

Xiaofan_Chen · July 20

@Tim_Roberts said:
If it is a PnP INF file, then the CAT file has to be signed. The SYS isn't enough.

Yes, the CAT file will be signed by the dpscat utility which is based on libwdi. After that the driver package can be installed using dpinst.

Xiaofan_Chen · July 20

Example run log using dpscat (based on libwdi).
.sys file is from Cypress.
The result driver package works fine under Windows 10 and Windows 11.

Reference:
https://github.com/pbatard/libwdi/issues/191

C:\work\libusb\libusbK-3.1.0.0-bin\bin\exe\amd64\cyusb3\Win10\x64> .\dpscat.exe
Copyright(c) 2012 Travis Lee Robinson. (DUAL BSD/GPL)
Portions Copyright(c) Pete Batard. (LGPL)
C:\work\libusb\libusbK-3.1.0.0-bin\bin\exe\amd64\cyusb3\Win10\x64>
Actual section to install: Device.NTamd64
Found Hwid: USB\VID_04B4&PID_00FC
Found Hwid: USB\VID_04B4&PID_00FE
Found Hwid: USB\VID_04B4&PID_00FD
Found Hwid: USB\VID_04B4&PID_00FB
Hash calculated for: .\cyusb3.inf
Using INF guid..
Hash added..
Catalog file 'CYUSB3.cat' created..
Deleted existing certificate: CN="Cypress (cyusb3.inf) [Self]" (Root store)
Deleted existing certificate: CN="Cypress (cyusb3.inf) [Self]" (TrustedPublisher store)
Set Enhanced Key Usage, URL and CPS..
Created new key container..
Generated new keypair.
Created new self-signed certificate: CN="Cypress (cyusb3.inf) [Self]"
Added CN="Cypress (cyusb3.inf) [Self]" certificate to 'Root' and 'TrustedPublisher' stores..
Signed file: C:\work\libusb\libusbK-3.1.0.0-bin\bin\exe\amd64\cyusb3\Win10\x64\CYUSB3.cat
Deleted private key..
Success!

Xiaofan_Chen · July 20

This is another example to use libusb-win32 device driver (libusb0.sys 1.2.7.3 version using Windows attestation signing) to replace Windows USB Composite Parent driver.

Here I am using Zadig which is part of the libwdi project.

Using inf name: USBasp_(Composite_Parent).inf
Successfully extracted driver files.
libwdi:info [wdi_prepare_driver] K driver available - adding the libusbK DLLs to the libusb-win32 inf
libwdi:info [extract_binaries] Successfully extracted driver files to 'C:\Users\xfchen\usb_driver'
libwdi:info [wdi_prepare_driver] Successfully created 'C:\Users\xfchen\usb_driver\USBasp_(Composite_Parent).inf'
libwdi:info [wdi_prepare_driver] Creating and self-signing a .cat file...
libwdi:info [wdi_prepare_driver] Test signing is: Disabled
libwdi:debug [AddFileHash] 'libusb0.dll': PE type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\xfchen\usb_driver\amd64\libusb0.dll'
libwdi:debug [AddFileHash] 'libusb0.sys': PE type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\xfchen\usb_driver\amd64\libusb0.sys'
libwdi:debug [AddFileHash] 'libusb0_x86.dll': PE type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\xfchen\usb_driver\amd64\libusb0_x86.dll'
libwdi:debug [AddFileHash] 'libusbk.dll': PE type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\xfchen\usb_driver\amd64\libusbk.dll'
libwdi:debug [AddFileHash] 'libusbk_x86.dll': PE type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\xfchen\usb_driver\amd64\libusbk_x86.dll'
libwdi:debug [AddFileHash] 'usbasp_(composite_parent).inf': INF type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\xfchen\usb_driver\usbasp_(composite_parent).inf'
libwdi:debug [AddFileHash] 'libusb0.dll': PE type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\xfchen\usb_driver\x86\libusb0.dll'
libwdi:debug [AddFileHash] 'libusb0.sys': PE type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\xfchen\usb_driver\x86\libusb0.sys'
libwdi:debug [AddFileHash] 'libusb0_x86.dll': PE type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\xfchen\usb_driver\x86\libusb0_x86.dll'
libwdi:debug [AddFileHash] 'libusbk.dll': PE type
libwdi:info [ScanDirAndHash] added hash for 'C:\Users\xfchen\usb_driver\x86\libusbk.dll'
libwdi:info [CreateCat] Successfully created file 'C:\Users\xfchen\usb_driver\USBasp_(Composite_Parent).cat'
libwdi:debug [CreateSelfSignedCert] Set Enhanced Key Usage, URL and CPS
libwdi:debug [CreateSelfSignedCert] Created new key container
libwdi:debug [CreateSelfSignedCert] Generated new keypair...
libwdi:info [CreateSelfSignedCert] Created new self-signed certificate 'CN=USB\VID_16C0&PID_05DC (libwdi autogenerated)'
libwdi:debug [SelfSignFile] Successfully created certificate 'CN=USB\VID_16C0&PID_05DC (libwdi autogenerated)'
libwdi:info [SelfSignFile] Added certificate 'CN=USB\VID_16C0&PID_05DC (libwdi autogenerated)' to 'Root' and 'TrustedPublisher' stores
libwdi:info [SelfSignFile] Successfully signed file 'C:\Users\xfchen\usb_driver\USBasp_(Composite_Parent).cat'
libwdi:info [SelfSignFile] Successfully deleted private key
Installing driver. Please wait...
...
...
libwdi:debug [process_message] Switching timeout back to finite
libwdi:debug [installer process] driver update completed
libwdi:debug [installer process] re-enumerating driver node USB\VID_16C0&PID_05DC\0001...
libwdi:debug [installer process] re-enumeration succeeded...
libwdi:debug [process_message] Installer process completed
libwdi:debug [installer process] successfully restored the system restore point creation setting
Driver Installation: SUCCESS

Xiaofan_Chen · July 20

Result of the above installation.
https://github.com/pbatard/libwdi/issues/191#issuecomment-1643545517

Xiaofan_Chen · July 20

BTW, libusbK-inf-wizard can generate driver package on the fly.

The driver installer InstallDriver.exe uses dpscat for the signing and dpinst for the driver installation.

You can see initially there is only .sys and .inf file and there is no .cat file.

After running the driver installer, you can see that .cat file is generated. You can now use dpinst to install the driver package as well.

C:\temp\USBasp_Composite_Parent> dir

    Directory: C:\temp\USBasp_Composite_Parent

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----           7/20/2023  4:38 PM                amd64
d----           7/20/2023  4:38 PM                x86
-a---           7/20/2023  4:38 PM        3685880 _DriverFiles.7z
-a---           7/20/2023  4:38 PM         587776 7za.exe
-a---           7/20/2023  4:38 PM            135 7zDP_LZMA.cfg
-a---           7/20/2023  4:38 PM          99328 7ZDP_LZMA.sfx
-a---           7/20/2023  4:38 PM            661 dpinst.xml
-a---           7/20/2023  4:38 PM         921992 dpinst32.exe
-a---           7/20/2023  4:38 PM        1050104 dpinst64.exe
-a---           7/20/2023  4:38 PM          34304 dpscat.exe
-a---           7/20/2023  4:38 PM        3785343 InstallDriver.exe
-a---           7/20/2023  4:38 PM           3840 Instructions.txt
-a---           7/20/2023  4:38 PM           1858 re-pack-files.cmd
-a---           7/20/2023  4:38 PM           9802 USBasp_Composite_Parent.inf

C:\temp\USBasp_Composite_Parent> dir .\amd64\

    Directory: C:\temp\USBasp_Composite_Parent\amd64

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           7/20/2023  4:38 PM          76384 libusb0.dll
-a---           7/20/2023  4:38 PM         193536 libusbK.dll
-a---           7/20/2023  4:38 PM         118072 libusbK.sys
-a---           7/20/2023  4:38 PM        1721576 WdfCoInstaller01009.dll

C:\temp\USBasp_Composite_Parent> dir .\x86\

    Directory: C:\temp\USBasp_Composite_Parent\x86

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           7/20/2023  4:38 PM          67680 libusb0_x86.dll
-a---           7/20/2023  4:38 PM         162816 libusbK_x86.dll
-a---           7/20/2023  4:38 PM          97976 libusbK.sys
-a---           7/20/2023  4:38 PM        1461992 WdfCoInstaller01009.dll

C:\temp\USBasp_Composite_Parent> .\InstallDriver.exe
Copyright(c) 2012 Travis Lee Robinson. (DUAL BSD/GPL)
Portions Copyright(c) Pete Batard. (LGPL)

Actual section to install: LUsbK_DeviceGroup.NTamd64
Found Hwid: USB\VID_16C0&PID_05DC
Hash calculated for: .\amd64\wdfcoinstaller01009.dll
Using PE guid..
Hash added..
Hash calculated for: .\amd64\libusbk.sys
Using PE guid..
Hash added..
Hash calculated for: .\amd64\libusbk.dll
Using PE guid..
Hash added..
Hash calculated for: .\amd64\libusb0.dll
Using PE guid..
Hash added..
Hash calculated for: .\x86\libusb0_x86.dll
Using PE guid..
Hash added..
Hash calculated for: .\x86\libusbk_x86.dll
Using PE guid..
Hash added..
Hash calculated for: .\USBasp_Composite_Parent.inf
Using INF guid..
Hash added..
Catalog file 'USBasp_Composite_Parent.cat' created..
Deleted existing certificate: CN="libusbK (USBasp_Composite_Parent.inf) [Self]" (Root store)
Deleted existing certificate: CN="libusbK (USBasp_Composite_Parent.inf) [Self]" (TrustedPublisher store)
Set Enhanced Key Usage, URL and CPS..
Created new key container..
Generated new keypair.
Created new self-signed certificate: CN="libusbK (USBasp_Composite_Parent.inf) [Self]"
Added CN="libusbK (USBasp_Composite_Parent.inf) [Self]" certificate to 'Root' and 'TrustedPublisher' stores..
Signed file: C:\temp\USBasp_Composite_Parent\USBasp_Composite_Parent.cat
Deleted private key..
Success!

C:\temp\USBasp_Composite_Parent> dir

    Directory: C:\temp\USBasp_Composite_Parent

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----           7/20/2023  4:38 PM                amd64
d----           7/20/2023  4:38 PM                x86
-a---           7/20/2023  4:38 PM        3685880 _DriverFiles.7z
-a---           7/20/2023  4:38 PM         587776 7za.exe
-a---           7/20/2023  4:38 PM            135 7zDP_LZMA.cfg
-a---           7/20/2023  4:38 PM          99328 7ZDP_LZMA.sfx
-a---           7/20/2023  4:38 PM            661 dpinst.xml
-a---           7/20/2023  4:38 PM         921992 dpinst32.exe
-a---           7/20/2023  4:38 PM        1050104 dpinst64.exe
-a---           7/20/2023  4:38 PM          34304 dpscat.exe
-a---           7/20/2023  4:38 PM        3785343 InstallDriver.exe
-a---           7/20/2023  4:38 PM           3840 Instructions.txt
-a---           7/20/2023  4:38 PM           1858 re-pack-files.cmd
-a---           7/20/2023  4:41 PM           4644 USBasp_Composite_Parent.cat
-a---           7/20/2023  4:38 PM           9802 USBasp_Composite_Parent.inf

C:\temp\USBasp_Composite_Parent> .\dpinst64.exe
C:\temp\USBasp_Composite_Parent>

Xiaofan_Chen · July 20

For those who are interested, dpscat is here. It is not limited to USB driver, it should work for all kind of drivers as long as the .sys is signed properly.
https://github.com/mcuee/libusbk/tree/master/libusbK/src/dpscat (libusbk has dual license, BSD or GPL v3 license, but libwdi is LGPL v3).

Creates self-signed .cat files from .inf files.  By default, dpscat.exe
searches the working directory for all files matching the FileSpec
*.inf.

USAGE:
dpscat.exe [/PATH Path]

/PATH Path   - Specifies an alternate .inf file search directory.

It uses the following two key files from libwdi project.
https://github.com/mcuee/libusbk/blob/master/libusbK/src/dpscat/pki.c
https://github.com/mcuee/libusbk/blob/master/libusbK/src/dpscat/mssign32.h

Latest libwdi version of the above two files (LGPL license)
https://github.com/pbatard/libwdi/blob/master/libwdi/pki.c
https://github.com/pbatard/libwdi/blob/master/libwdi/mssign32.h

Tim_Roberts · July 20

But, hang on. This is performing the same function as inf2cat, right? It certainly can't apply a Microsoft signature to the CAT file, and without that, it can't satisfy KMCS. Right?

Peter_Viscarola_(OSR) · July 20

certificates in the trusted root need to have specific key usage and hierarchy requirements or they are ignored by the system.

I dunno. WHICH key usages do they need, specifically? Cuz the cert I used (as you can see) is just a self-signed cert (created by the WDK automagically for test signing purposes).

This is certainly not the case when you enable Test Signing (which requires you put the cert in the Root Cert Auth store for the machine).

@rob18767

Which is available until 2029 as version '17763' (1809). This is what I develop with at work for now.

Sure. Fine. But, regardless of IoT, not IoT, Sever, or whatever... You can't Attestation Sign an ISA driver anymore. SO, if one of the drivers for an ISA device needs to be fixed, you are screwed. Full stop. The MSFT decision to do this seems... "unwise" in my most humble opinion.

Though, I admit, my bigger issue is all the folks on the planet that are using devices/systems based on Windows "embedded" (whatever the name of the month is) 7, 8.0, and 8.1. There is currently no way, none at all, to update ANY driver for these systems unless you can pass the full set of Logo Tests. And, I'm guessing that the custom system board, stuffed into the hatch on a drone, for which I wrote a driver for the C3I system, is never going to pass those tests. Actually, I'm not guessing. I'm saying: It's never going to pass those tests. Never. Ever. No way. No how. That's not the fault of the system... which demonstrably works "as designed" -- It's a matter of what the tests require. Which really, truly, have nothing to do with the behaviors we want on an embedded system.

Sorry... you can probably tell this is a sore spot for me. Medical equipment, military equipment, shop floor, process control, industrial vision... the logo tests make no sense for these systems, but that is now the only way you can put a new driver on one of these machines if they're not running Windows 10 or later.

Peter

Gregory_G._Dyess · July 20

Windows Embedded family (Windows Embedded Compact 13, Windows Embedded 7, Windows CE 6...) did not have signed drivers or any mechanism to enforce driver signing. They didn't even look anything at all like a desktop Windows driver (except for NDIS nightmare).

I can't speak to Windows 10 IoT or Windows 10 (Enterprise?? or otherwise). I left the Windows Embedded world at Windows 10 IoT. The desktop driver model is just WAY too heavy weight to try to force upon a truly embedded system running an ARM core at 1 GHz with 1GB RAM and having even soft realtime requirements.

Greg

On Thu, 20 Jul 2023 20:05:53 +0000 (UTC), "Peter_Viscarola_(OSR)" wrote:

OSR https://community.osr.com/

Peter_Viscarola_(OSR) commented on Driver Development- Found Legacy Operation "LogConfig" and "FactDef"

> certificates in the trusted root need to have specific key usage and hierarchy requirements or they are ignored by the system.

I dunno. WHICH key usages do they need, specifically? Cuz the cert I used (as you can see) is just a self-signed cert (created by the WDK automagically for test signing purposes).

This is certainly not the case when you enable Test Signing (which requires you put the cert in the Root Cert Auth store for the machine).

@rob18767

> Which is available until 2029 as version '17763' (1809). This is what I develop with at work for now.

Sure. Fine. But, regardless of IoT, not IoT, Sever, or whatever... You can't Attestation Sign an ISA driver anymore. SO, if one of the drivers for an ISA device needs to be fixed, you are screwed. Full stop. The MSFT decision to do this seems... "unwise" in my most humble opinion.

Though, I admit, my bigger issue is all the folks on the planet that are using devices/systems based on Windows "embedded" (whatever the name of the month is) 7, 8.0, and 8.1. There is currently no way, none at all, to update ANY driver for these systems unless you can pass the full set of Logo Tests. And, I'm guessing that the custom system board, stuffed into the hatch on a drone, for which I wrote a driver for the C3I system, is never going to pass those tests. Actually, I'm not guessing. I'm saying: It's never going to pass those tests. Never. Ever. No wya. No how. That's not the fault of the system... which demonstrably works "as designed" -- It's a matter of what the tests require. Which really, truly, have nothing to do with the behaviors we want on an embedded system.

Sorry... you can probably tell this is a sore spot for me. Medical equipment, military equipment, shop floor, process control, industrial vision... the logo tests make no sense for these systems, but that is now the only way you can put a new driver on one of these machines if they're not running Windows 10 or later.

Peter

rob18767 · July 21

@Peter_Viscarola_(OSR) said:

@rob18767

Which is available until 2029 as version '17763' (1809). This is what I develop with at work for now.

Sure. Fine. But, regardless of IoT, not IoT, Sever, or whatever... You can't Attestation Sign an ISA driver anymore. SO, if one of the drivers for an ISA device needs to be fixed, you are screwed. Full stop. The MSFT decision to do this seems... "unwise" in my most humble opinion.

Yeah I had a think about this. If the dashboard refuses to sign an ISA driver, even when select 1809 x64 Client to sign for self attestation, then you cannot sign you driver no matter what (as you said).

Microsoft states the long term service channel on the version we use is available until 2029 for IoT developers. To suddenly not be able to sign a driver for whatever reason would be, at the very least, infuriating.

@Gregory_G._Dyess said:
Windows Embedded family (Windows Embedded Compact 13, Windows Embedded 7, Windows CE 6...) did not have signed drivers or any mechanism to enforce driver signing. They didn't even look anything at all like a desktop Windows driver (except for NDIS nightmare).

I can't speak to Windows 10 IoT or Windows 10 (Enterprise?? or otherwise). I left the Windows Embedded world at Windows 10 IoT. The desktop driver model is just WAY too heavy weight to try to force upon a truly embedded system running an ARM core at 1 GHz with 1GB RAM and having even soft realtime requirements.

Greg

Windows said they were going to replace Windows CE with Windows IoT core.

We developed a CE product from the open source hardware Beaglebone board. Apparently we cannot use this hardware with Windows 10 IoT core because the interrupt structure on the CPU was TI's own as opposed to ARM.

We have CE platform builders for CE 7.0 and Embedded Compact 2013. It would be ridiculous to have to sign drivers for CE. We can keep going for a bit longer yet. \

And please, Microsoft, for my sanity's sake do not force me down the Linux route again.

Xiaofan_Chen · July 21

@Tim_Roberts said:
But, hang on. This is performing the same function as inf2cat, right? It certainly can't apply a Microsoft signature to the CAT file, and without that, it can't satisfy KMCS. Right?

I do not know the technical details but libwdi/Zadig/libusbK-inf-wizard has been working for quite some time, including Windows XP/Vista/7/8.1/10/11.

There were reports that the method does not work for certain insider version of Windows 10/11. It is also found that the method does not work for Windows 11 on ARM64.

It does have a major pre-requsite that the .sys driver needs to have valid signature.

Peter_Viscarola_(OSR) · July 21

...to suddenly not be able to sign a driver for whatever reason would be, at the very least, infuriating.

This.

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

Before Posting...

More Info on Driver Writing and Debugging

Driver Development- Found Legacy Operation "LogConfig" and "FactDef"

Comments

Howdy, Stranger!

Quick Links

Categories