This driver has been blocked from loading on Win 11 and 10 x64

[Michael]

I have a 32 bit app, loading a 32 bit InpOut32.dll running just fine on a Win 7 and Win 10 x86.
The same (Running the 32 bit app (process) loading a 32 bit InpOut32.dll) does not work on Win 11 or Win 10 x64.
I was told, I should have NO ISSUES, loading and running a 32bit driver on a 64bit OS as long as the app accessing the driver is also 32bit process.

hdriver = CreateFile("\\\\.\\hwinterface",
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);

Get Last Error returns 0x2 for last error (File not found)
ERROR_FILE_NOT_FOUND
2 (0x2)
The system cannot find the file specified.

Event Viewer shows
The hwinterface service failed to start due to the following error:
This driver has been blocked from loading

It looks like someone else was having a similar issue 9 years ago. LOL
https stackoverflow com/questions/34956231/where-is-hwinterface-sys-for-controling-lpt
It looks like someone is referring your website as a solution.

Not sure what run as an Administrator means.
Run what as an administrator? The app itself or just the driver dll.
Not to mention the fact that, I do not know how one would load and run the dll as an admin..

Your sample (unfortunately does not compile) Inpout32_dll_source_1501
is using the file name (inpout32.dll) as the path.

TCHAR szFileName[MAX_PATH] = {NULL};
_stprintf_s(szFileName, MAX_PATH, _T("\\\\.\\%s"), bX64 ? DRIVERNAMEx64 : DRIVERNAMEi386);

hdriver = CreateFile(szFileName,
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);

What am I doing wrong.
Any suggestion would be much appreciated.

Regards
Michael

[phil]

You absolutely can not load a 32bit driver on 764bit OS;'s.
You can load a 32bit DLL that talks to a 64bit driver - and that is what MY port of InpOut32.dll is, a 32bit DLL that contains both x86 and x64 drivers, installing and loading the relevant one at runtime.

The DLL is NOT the driver. The driver is a .SYS file (embedded into the DLL, extracted at runtime (to the c:\windows\system32 folder (or c:\windows\system32\drivers - I cant recall) and installed.

If you are not using my port of InpOut32.dll then I would guess you don't have the required 64bit driver inside of it.
Where did you get the DLL and what version is it. Find the latest here.... https://www.highrez.co.uk/downloads/inpout32

As for running as administrator, that is required to install drivers (so the first time you use the DLL). You run as administrator by starting the process (the EXE calling the DLL) as admin. My distribution has an InstallDriver.exe which forces this for ease of use but you can achieve the same by running your process as admin the first time to ensure the driver gets installed.

Once the driver is installed, you should see it under the "legacy devices" in device manager.

PS. I no longer support this project, it is ancient and I dont have the tools or ability to sign drivers anymore - the requirements to get hold of a driver signing certificate require you to be a publicly trading company etc. Not something a hobbyist can do these days

[phil]

Just re-read your post...

You are trying to load the driver \\.\hwinterface - That is the 32bit driver which is why it won't work on 64bit OS's.
The sample from my code that you quoted saying it wont compile (no idea why that would be it compiled the last time I tried it but that was over 10 years ago lol) uses a boolean which is set to true for x64 and false for x86, using the relevant driver name (DRIVERNAMEx64 for x64 or DRIVERNAMEi386 for x86). That is what you need to do.

[Michael]

THANK YOU very much Phil.
I will keep you updated.

[Michael]

I had noticed, your sample is using
_stprintf_s(szFileName, MAX_PATH, _T("\\\\.\\%s"), bX64 ? DRIVERNAMEx64 : DRIVERNAMEi386);

either DRIVERNAMEx64 ("inpoutx64\0") or DRIVERNAMEi386 ("inpout32\0")
I am assuming these are the sys files located in root path \\\\.\\

I am able to locate both InpOutx64.sys and InpOut32.sys from 6/15/2013...
Does that mean, if I modify my DllMain OpenDriver to match yours and copy the sys files appropriately to
System32\Drivers and sysWow64\Drives. When executing I will be able to get appropriate file handle (hdriver)
***************************************************************************************
How are these .sys files are created? Are these standard or can or should they be modified.
I am not sure if hwinterface.sys that I have access to was modified. If it was, I do not have access to the source)
***************************************************************************************
I also noticed, my inpout32drv.cpp is different then the one you provided..

It has additional #define for dwIoControlCode (see below, not sure if all these are getting used)
Does this mean, I would need SPECIAL InpOutx64.sys and InpOut32.sys that will be able to process these??

#define IOCTL_READ_PORT_UCHAR -1673519100 //CTL_CODE(40000, 0x801, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_WRITE_PORT_UCHAR -1673519096 //CTL_CODE(40000, 0x802, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_SELECT_CONTROLLER -1673519076 //CTL_CODE(40000, 0x807, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_WRITE_ADDRESS -1673519072 //CTL_CODE(40000, 0x808, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_WRITE_VALUE -1673519068 //CTL_CODE(40000, 0x809, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_DRAW_LCD_SCREEN -1673519052 //CTL_CODE(40000, 0x80D, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_LCD_INIT -1673519048 //CTL_CODE(40000, 0x80E, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_GET_BUTTON -1673519044 //CTL_CODE(40000, 0x80F, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_RELEASE_BUTTON -1673519040 //CTL_CODE(40000, 0x810, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_GET_ALL_DEVICES -1673519036 //CTL_CODE(40000, 0x811, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_INIT_SPEC -1673519032 //CTL_CODE(40000, 0x812, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_GATHER_SPEC -1673519028 //CTL_CODE(40000, 0x813, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_INIT_KEYS -1673519024 //CTL_CODE(40000, 0x814, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_LOOKUP_KEY -1673519020 //CTL_CODE(40000, 0x815, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_SELECT_PROD -1673519016 //CTL_CODE(40000, 0x816, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_SET_BUZZER_FREQ -1673519012 //CTL_CODE(40000, 0x817, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_SET_BUZZER_STATE -1673519008 //CTL_CODE(40000, 0x818, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_INITGATHER_SPEC -1673519004 //CTL_CODE(40000, 0x819, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_SET_POLARITY -1673519000 //CTL_CODE(40000, 0x820, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_READ_SERIAL -1673518996 //CTL_CODE(40000, 0x821, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_READ_SERIAL_UNSIGNED -1673518992 //CTL_CODE(40000, 0x822, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_INIT_SPEC_H150 -1673518988 //CTL_CODE(40000, 0x823, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_GATHER_SPEC_H150 -1673518984 //CTL_CODE(40000, 0x824, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_READ_ADDRESS -1673518980 //CTL_CODE(40000, 0x825, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_INIT_SPEC_B220U -1673518976 //CTL_CODE(40000, 0x826, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_GATHER_SPEC_B220U -1673518972 //CTL_CODE(40000, 0x827, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_WRITE_ADDRESS_DEBUG -1673518968 //CTL_CODE(40000, 0x828, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_READ_EEPROMKEY_DEBUG -1673518964 //CTL_CODE(40000, 0x829, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_SET_SERIAL_TIMEOUT_SCALER -1673518960 //CTL_CODE(40000, 0x830, METHOD_BUFFERED, FILE_ANY_ACCESS)

[phil]

The sys files are embedded in the DLL, at runtime (first) they are saved to disk and installed - that’s why you need elevated admin access!

\\\\.\\ (\\.\) is not a path on disk it’s the diver root location - means something to Windows….

Originally the .sys files were compiled from the Driver CPP file(s) that are all available on my website.

HWInterface.sys it the original (32bit only) version from Logix4u (the author of Inpout32 which my project was originally cloned from). I renamed it inpout32 for clarity along with inpoutx64! Indeed badder additional signatures from DLPortIO another project like InpOut32 to make it compatible with either. You don’t have to use them.

There is a bug in the driver for ulong port access - simply does not work. I can’t fix it even if I wanted to (reasons below)

Really you should be interfacing to the DLL and not loading the drivers directly (especially if you can’t figure out how it all works!!)

Everything source and example wise is on my website, but as I said, I no longer have the ability to sign drivers ;a friendly user with software signing certificates signed the .sys files for me! It’s not something your average hobbyist can do anymore!

Therefore I can no longer support it. You are on your own (and if the current signature ever gets revoked we are all screwed (well I’m ok as I haven't use me inpout32/x64 for years!

Of course anyone can rebuild and resign the files themselves if they can get hold of certificates to do so. It was built with a very old (now) SDK so maybe changes are required to follow all the more recent rules - I don’t know and I’m not in a position (nor interested) to find out.

All my IO requirements these days are done with USB, Pi or arduino devices likes it’s own he 2020’s!

Regards,
Phil

[Michael]

Thank you SO MUCH Phil.

[dbjh]

There is a bug in the driver for ulong port access - simply does not work.

DlPortWritePortUlong() does not work as intended, but DlPortReadPortUlong() does. Saying that DlPortWritePortUlong() simply does not work ignores the fact that it definitely does something, namely write to a pseudorandom I/O port address. I wonder whether that can cause actual issues, but it is a genuine bug.

I can’t fix it even if I wanted to (reasons below)

Yes, you can, if you wanted to. You have made it abundantly clear that you will not be able to get a newly built driver signed, but you can address it in the DLL instead. In client code the following statement:

Code: Select all

DlPortWritePortUlong(port, value);

should be replaced with the following two:

Code: Select all

DlPortWritePortUshort(port, (USHORT)value);
DlPortWritePortUshort(port + 2U, (USHORT)(value >> 16));

It would be responsible to do that in the DLL instead, to avoid undefined behavior (in hardware). For example, if people don't test their software properly.

All my IO requirements these days are done with USB, Pi or arduino devices likes it’s own he 2020’s!

Seeing a statement like that makes me doubt whether you understand who is using your software and what for.

[Michael]

Thank you all for all the great replies.

Earlier it was mentioned: ( see in bold)
You absolutely can not load a 32bit driver on 764bit OS;'s.
You can load a 32bit DLL that talks to a 64bit driver - and that is what MY port of InpOut32.dll is, a 32bit DLL that contains both x86 and x64 drivers, installing and loading the relevant one at runtime.

However, when I Google "Can you load a x64 driver from a 32 bit dll"
I am getting..
[b]No, you cannot load an x64 driver from a 32-bit DLL on a 64-bit Windows system;[/b] a 32-bit process cannot directly load a 64-bit DLL, including device drivers, due to the fundamental difference in memory addressing between the two architectures.

OR
search "Loading a x64but driver to a 32 bit dll"
It is not possible to load a 64-bit (x64) driver into a 32-bit DLL;



So, which one is it?
Has anyone tried this?

[phil]

All I am going by is what I did myself 15 years (or so ago). I may be wrong and my InpOut32.dll may not work (although evidence over the last 15 years refutes that). Not everything on google is gospel you know!

However, its quite possibly a terminology issue. I mean the DLL isn't strictly loading the driver, its just making calls to it. The driver is loaded by Windows itself, not the DLL (the DLL tell's windows to install it, and then it communicates with it).

Also when I google "Can you load a x64 driver from a 32 bit dll" it seems to be getting very confused with loading an x64 DLL into an x86 (32bit) process - which for sure you CAN NOT do - but that's why I provide both a 32bit DLL (inpout32.dll) for 32bit processes, and Inpoutx64.dll for 64bit processes (or both if your using .NET in "any CPU mode" where you have to decide which .DLL to use and load appropriately at runtime based on the mode you are running (x86 or x64). None of that however is relating to talking to a 64bit driver, running on 64bit windows from a 32bit process. I mean if that was not possible, how would ANY 32bit process communicate with system devices?!

I'm afraid I'm out of responses other than that. As I said, I haven't worked on this for years, and as I said previously, I no longer support it. I didn't write it and my experience with drivers is limited to compiling Logix4U's code to x64. Frankly, I see no reason for it to be used in 2025 and anything that is attempting to use it in 2025 is at your own risk, I mean MS could break it completely forever at any time simply by revoking the certificate it was signed with (or by enforcing newer AES256 signatures which is on the cards, but hasn't yet been done in Win11. Then it is no more (unless you can compile and sign the driver yourself of course).

[phil]

I can’t fix it even if I wanted to (reasons below)

Yes, you can, if you wanted to. You have made it abundantly clear that you will not be able to get a newly built driver signed, but you can address it in the DLL instead. In client code the following statement:

Code: Select all

DlPortWritePortUlong(port, value);

should be replaced with the following two:

Code: Select all

DlPortWritePortUshort(port, (USHORT)value);
DlPortWritePortUshort(port + 2U, (USHORT)(value >> 16));

It would be responsible to do that in the DLL instead, to avoid undefined behavior (in hardware). For example, if people don't test their software properly.

I'm not sure about that, maybe you are right (looks reasonable) but either way, as I have said over and over again on the forums, I no longer support this software. The code is all all available for others to modify as they see fit and if it is possible to fix it in the DLL then all power to those who choose to do so.

In fact I believe someone has already done this... viewtopic.php?p=22778#p22778 which I believe you are familiar with. No idea if that project went any further than was reported here. Oh it seems they don't have a signed driver

All my IO requirements these days are done with USB, Pi or arduino devices likes it’s own he 2020’s!

Seeing a statement like that makes me doubt whether you understand who is using your software and what for.

You should absolutely doubt that - I have no absolutely no knowledge of who or what is using InpOut32 (how could/why should I?).
I also wouldn't call it "my" software as Logix4U wrote it, not I. I only ported InpOut32 to x64 (as it made clear in the first paragraph of the download page).

However, it looks like I do need to update the main download page, to make it clear that I no longer support this software myself (I confess I thought I had done that before, but maybe I'm just thinking about on the forums). I will certainly so that, but there will come a time where perhaps removing the pages from my website and the forum would be more appropriate? Like the original author Logix4U appears to have done

In reality, surely no self respecting company (particularly) or individual (to a lesser extent I guess) should be using 14 year old unsupported software, especially that gives direct hardware access and kernel level drivers. I would like to think if I did that at work, it would result fail any code review That does not mean that no one can "fork" it and support it themselves. For example, if a company or commercial project depends on InpOut32 then they should be able to get the necessary certificates to sign the drivers and be able to employ the necessary resources to maintain and support it themselves (either in an open sense or a closed sense) if they depended upon it that much.

[Michael]

Thank you again all.
Ultimately, we may have to hire a consultant with Win Device driver experience.

[Michael]

Since hwinterface.sys is the driver...
InpOut32.dll and InpOutx64.dll is the Dynamic link library.

Where is the x64 driver?

If I can get a hold of hwinterfacedrv.c and recompile as x64, would that be the x64 driver? or would I need to make additional changes to hwinterfacedrv.c

[phil]

Just to be clear, hwinterface.sys is not the driver, at least, not in my port.
It is what the driver was called in the original, 32bit only Logix4U version (and maybe early versions of my port (for the 32bit driver)).

The more recent (10yr old lol) builds of my port, such as v1.5.0.1, the drivers files are named inpout32.sys and inpoutx64.sys which are the 32bit and 64bit drivers respectively.

They are embedded resources in the DLL's and they are individually available in the source code for the DLL's link on my website as well as the source code for the driver is what created them (but as you have found, you probably need the 2005 Driver DDK to build them, not the latest DDKs as the architecture has changed requiring code changes (I guess).

DLLSource.png

[Michael]

What do I need to compile hwinterfacedrv.c
Trying to compile HWInterfaceDrv project. Too many errors, I lost count