Problem starting the driver from the DLL

My x64 port of InpOut32
Post Reply
rlma2
New User
Posts: 4
Joined: Wed Oct 28, 2009 2:40 pm

Problem starting the driver from the DLL

Post by rlma2 »

To be truthful I've run into this problem in the 32 bit version of the dll but, IMO, is equally applicable to the 64 bit DLL version.

If the driver has been stopped ( using, say, "net stop inpout32") when the application using the inpout32.dll et al is ran the driver is successfully started but the input and output calls all fail because no handle was gotten for the driver.
Here's the perennate original code (of v1.0.0.8) in Opendriver.

Code: Select all

	if(hdriver == INVALID_HANDLE_VALUE) 
	{
		if(start(bX64 ? DRIVERNAMEx64 : DRIVERNAMEi386))
		{
			if (bX64)
				inst64();	//Install the x64 driver
			else
				inst32();	//Install the i386 driver

			start(bX64 ? DRIVERNAMEx64 : DRIVERNAMEi386);

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

			if(hdriver != INVALID_HANDLE_VALUE) 
			{
				OutputDebugString("Successfully opened ");
				OutputDebugString(bX64 ? DRIVERNAMEx64 : DRIVERNAMEi386);
				OutputDebugString(" driver");
				return 0;
			}
		[b]}[/b]
		return 1;
	}
The correction would be as follows showing moving the marked "}" from the "start" so that a successful start attempts to get a driver handle.

Code: Select all

	if(hdriver == INVALID_HANDLE_VALUE) 
	{
		if(start(bX64 ? DRIVERNAMEx64 : DRIVERNAMEi386))
		{
			if (bX64)
				inst64();	//Install the x64 driver
			else
				inst32();	//Install the i386 driver

			start(bX64 ? DRIVERNAMEx64 : DRIVERNAMEi386);
		[b]}[/b]
		hdriver = CreateFile(szFileName, 
			GENERIC_READ | GENERIC_WRITE, 
			0, 
			NULL,
			OPEN_EXISTING, 
			FILE_ATTRIBUTE_NORMAL, 
			NULL);

		if(hdriver != INVALID_HANDLE_VALUE) 
		{
			OutputDebugString("Successfully opened ");
			OutputDebugString(bX64 ? DRIVERNAMEx64 : DRIVERNAMEi386);
			OutputDebugString(" driver");
			return 0;
		}
		return 1;
	}
The real problem but related problem I've ran into is still unresolved. The problem is the app that uses inpout32 is launched at startup. When the app is launched the driver hasn't started yet but apperently the dll still doesn't successfully start the driver and the app fails to be able to successfully perform the Opendriver until a short while later. It seems like the dll api will need something like a "ready" entry point that can confirm that the Opendriver succeeded and retry the open if previously the open had failed.
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: Problem starting the driver from the DLL

Post by phil »

And that's why you wanted the DLL sources .. lol OK I understand now :)

I will try and package it up later when I get home from work.
There is a function IsDriverOpen (or something similar) that I added some time after 1.0.0.0 to check that its open (but I'm not sure it re-opens it if it is not).

Phil
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
rlma2
New User
Posts: 4
Joined: Wed Oct 28, 2009 2:40 pm

Re: Problem starting the driver from the DLL

Post by rlma2 »

I had forgotten too what IsInpOutDriverOpen actually did. My recollection was that it was used by InstallDriver to actually do the work of install the driver. So I had filed it away in my mind as calling one of the instXX routines. Reviewing it I see it does just return the status of the Opendriver that dllmain performed. The actual driver installation is an artifact of DllMain trying to open the driver.
It seems like it would be consistent to also have it retry the open first if the previous open had failed.

There are major areas of 1.0.0.8 and 1.2.0.0 that are the same from what I see in the disassembly.
There are subtle differences and major additions.
1.0.0.8 is still using the hwinterface driver.
1.2.0.0 adds
  • OutputDebugsString with error code when Opendriver fails
    The commented out code for DlPortXXXPortUshort and DlPortXXXPortUlong are uncommented
    Support for MapPhysToLin, UnmapPhysicalMemory, GetPhysLong() and SetPhysLong
Last edited by rlma2 on Wed Oct 28, 2009 4:33 pm, edited 2 times in total.
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: Problem starting the driver from the DLL

Post by phil »

Heh fair enough, I'll sort out the code for you when Im home from work..

Incidentally, the "Support for MapPhysToLin, UnmapPhysicalMemory, GetPhysLong() and SetPhysLong" and possible the "commented out code for DlPortXXXPortUshort and DlPortXXXPortUlong" dont actually work as fart as I remember :|

There is no reason we could not modify it to re-try the open I guess.

Phil
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
rlma2
New User
Posts: 4
Joined: Wed Oct 28, 2009 2:40 pm

Re: Problem starting the driver from the DLL

Post by rlma2 »

Observations looking at the disasm of the DLL & driver (v1.2.0.0) for the read and write handlers.

In the driver the handler for DlPortWritePortUlong is different than all the others. When it calls WRITE_PORT_ULONG instead of passing the zero extended 16 bit port address from the input buffer, like all the other similar functions, it passes the address of the input buffer. Also different from the others, but non-fatal, it passes the value from offset 4 in the input buffer but all other write calls assume a 16 bit port address and get their value from offset 2 in the input buffer.

It appears that the dll knows about the inbuffer layout difference.
So only a double check is required to see if the port parameter to WRITE_PORT_ULONG is being properly obtained from inbuffer by the driver as to not break compatibility with the exitsing 1.2.0.0 DLLs.

If the driver isn't getting the port value correctly then Write Ulong definitely won't work.

Other than the above, it would appear that if the uchar functions of the driver work that the other ushort and ulong should also work except for write ulong mentioned above.

The following additional observations don't impact the operation of the other Read and Write API functions but make it hard to understand the logic behind the code if the observations are correct.

For DlPortReadPortUlong, the dll seems to have compatible but different layout of the inbuffer than the driver. The Dll puts a 32 bit port in the inbuffer and set the size to 4 but the driver only pulls out 16 bits. With little indian the difference isn't noticed.

In the dll DlPortWritePortUshort passes an inbuffer length of 5 but only 4 bytes are valid ( 2 for port and 2 for the value to write).

In the dll DlPortReadPortUshort passes an outbuffer length of 4 bytes but only 2 bytes are really returned. It also passes a 4 byte port address even though the driver only uses the first 2 bytes.

In the dll DlPortReadPortUchar passes an outbuffer length of 3 when only 1 is actuall filled by the driver and used by the dll. It also passes the inbuffer size of 3 when only 2 bytes are sent by the dll and used by the driver.
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: Problem starting the driver from the DLL

Post by phil »

Don't forget that I added the DlPortWritePort functions myself using the old DLportIO examples and possible some WinRing0 examples. But these functions were never in the InpOut32 code originally... And its *quite* possible I have messed up (and I've never tested them!).

Its pretty clear you know your stuff so once I get home and put the 1.2.0.0 code online your welcome to pick it apart and suggest improvements/fix it for me :)

If we have to change the driver, it could be a different matter as I will need to get it signed again - but hopefully thats not impossible. Do you have the latest driver sources (Im not sure if I updated them or not).

Thanks,
Phil
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: Problem starting the driver from the DLL

Post by phil »

OK, I've just updated the driver and DLL source code download links to provide the latest code.

Thanks,
Phil
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
Post Reply