I have an old 64-bit Windows kernel-mode driver which I created for a USB device. It was built for Windows XP. The driver still works in Windows 10 and Windows 11. However, if Core Isolation | Memory Integrity is turned on in the Windows Security app then the driver no longer works. I get the following error in Device Manager:
Windows cannot load the device driver for this hardware. The driver may be corrupt or missing (Code 39). {Bad Image}...
In the setupapi.dev.log file I get this error:
Device has problem: 0x27 (CM_PROB_DRIVER_FAILED_LOAD), problem status: 0xc000007b
Error 0xc000007b is STATUS_INVALID_IMAGE_FORMAT (the file is either not designed to run on Windows or it contains an error)
However, all these errors are red herrings because the file is not corrupt or missing and has the correct format (64-bit).
The driver and cat file are signed using a standard code-signing certificate. The driver has not been submitted for WHQL testing (this was expensive at the time).
Do you know how I can make this driver compatible with Core Isolation? Do I have to re-compile it, or re-sign it in some way, or submit for WHQL?
You say the driver still works for Windows 10, and let's assume it truly does. That it's rejected for having an invalid format does not of itself mean the driver doesn't work if it gets to execute, only that it didn't even get loaded.
With this as my input, my first guess off the top of my head is that you did this WHQL testing so long ago that the driver's signature has only a SHA-1 hash. For it to be loadable on everything from Windows XP to Windows 11, a necessary condition is that its signing has both SHA-1 and SHA-256 hashes.
One or other of the long articles I wrote at my website in 2018 has an example (if I remember correctly) of getting both hashes, but the bigger problem in practice for Windows 10 is that you won't be able to sign the driver yourself, even with the cross-signing that used to work, and have it load on 64-bit Windows when Secure Boot is enabled.
The formal, expected way to get an old driver signed for arbitrary configurations of Windows 10 is that you put it through the WHQL procedure all over. When last I looked, not that I bother looking at Microsoft's documentation often, it was supposed to be that you could specify that you want both hashes so that the driver still loads on old Windows versions.
Depending on what exactly your driver does, and I confess that I don't know off the top of my head where USB drivers of all sorts fit into this, you may be able to get away with attestation signing. This spares you from the WHQL testing, but again if you want the signing to work on old Windows versions you will have to say so when you submit.
I can't say I know the details of how Microsoft's procedure works, only of what signatures different Windows versions accept (and of how this differed from Microsoft's documentation in 2018). Unless this rough brain dump has something factually incorrect, I won't be following up. I make this contribution only because I hope your raising a practical question on an important issue can get more help, of just discussion, than it has.