Dlportio.sys Driver Not Loaded

[Billi Mayhue]

PresentationInstallation & Setup : Parallel Port not working Wesley Clapp

2004-12-06 14:49 UTC

Hello,

I just installed the newest version of Presentation and when I tried to run an existing experiment it came up with the error message "DLPORTIO.SYS" device driver not loaded. Port I/O will have no effect" and sure enough we are getting no triggers (i.e. the parallel port is not sending TTL pulses) however if we use another program (i.e. DOS or EPrime) the parallel port is sending triggers. Could you help? Thanks so much!

Well, either the installation program didn't do something right, or there's some other oddity about the system.

Make sure that the file "DLPORTIO.sys" is in "C:\Windows\System32\Drivers".

Then you could click "Run" from the start menu, type "regedit", then navigate to the key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DLPortIO", and see if it's there, and what's in it if it's there.

When we tried to run Pony Prog Parallel Programmer,we got the error msg "DLPORTIO.SYS device driver couldnot be loaded".We are running Windows Vista Ultimate Edition.Plz help us to Solve this problem.

Thanks!!

This would happen if you installed Presentation on a system for the first time, and ran it before rebooting.

If you have rebooted the machine since installing Presentation, this reflects some problem with the installation. I would try reinstalling the program. Actually, sometimes if something isn't right, if you go to the Windows add/remove software panel it will give you a "fix" option.

By the way, uninstalling and reinstalling shouldn't affect the activation on the machine.

Did you try reinstalling Presentation? Did you try what Peter recommended on Dec. 9, 2004? That is:

Make sure that the file "DLPORTIO.sys" is in "C:\Windows\System32\Drivers".

Then you could click "Run" from the start menu, type "regedit", then navigate to the key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DLPortIO", and see if it's there, and what's in it if it's there.

Alas, Windows 7 (and Vista) make it a bit more difficult to install this driver. It seems everything is allright running the installer (port95nt.exe), but running the program gives the error DLPORTIO.SYS is not loaded.

I expect to see the numbers from 1 to 9, but instead I see the number 148 which stays constant for the whole loop. The port address is correct -- if I use DirectRT, it will work just fine. I suspect that DlPortWritePortUchar is not working correctly. Can anyone suggest where to look for the problem?

Something wierd is going on. If I read the value of the ports with DlPortReadPortUchar or with the port_reader plugin, I see that the port is changed to the desired value. But PyCorder (a software to record EEG data, can recieve triggers) shows no sign of triggers. But when I use IOTest utility (part of DirectRT), then the triggers are recieved. The port number is the same in both cases. Sometimes it says that "dlportio.sys device driver not loaded", but the information from the port_reader is still correct. And no sign of the trigger in the PyCorder...

This error comes from a Windows library (.dll ) that the experiment fails to load. Presumably, the creator of the experiment installed this library manually and wrote a piece of inline_script that uses it. Can you post the inline_script that triggers the error?

This script assumes that you have a file called dlportio.dll , which can be used to communicate through the parallel port. You can download dlportio.dll from many places on the internet, including dll-files.com. However, it seems that only 32 bit versions exist of this driver, which means that it's not compatible with the current 64 bit OpenSesame packages. It may work with the (outdated) 3.0 packages though, so you can try that. To install the dll simply extract it to the OpenSesame program folder.

Thank you! Unfortunately, I now get a new error message (DLPORTIO.SYS device driver not loaded). Maybe it's because I'm trying to run a script on my laptop that was designed to take external input from a button box.

You're using a very old version of OpenSesame, and I suspect that this is simply a bug that was present at that point (but has been fixed since). Unless there is a good reason to do otherwise, I would always use the latest version!

Thank you so much! People who use OpenSesame regularly told me that older experiments don't always work with the newer versions, so I first ran the experiment with the version with which it was created. Now I now better! It runs perfectly in the latest version. Thanks a lot!

Users of application software that use (mainly) the parallel port usually complain that giveio.sys or dlportio.sys won't work on a 64-bit Windows version. Therefore, the recommendation was to either use a 32 bit Windows version instead, either native or in a Virtual Machine, or to upgrade the hardware to a USB version trashing the old hardware + software, if available. As parallel ports are still available as PCI, PCIexpress, or ExpressCard extensions, the problem not being upgradeable towards 64 bit remains. (I assume the reader expects AMD64, not the totally incompatible and almost dead Intel64 architecture.)

The application programs affected must be 32 bit, as 16 bit programs won't run on Windows 64bit either. Moreover, the programs have the I/O instructions inlined rather than calling a well-known DLL for each I/O, mostly inpout32.dll. For the latter case, an upgraded inpout32.dll would do the job since a couple of years.

As introduction of AMD64 architecture is long ago, I'm wondering that no someone else found such a solution beforehand. I coped with that problem redirecting that inlined I/O by injecting a DLL into the process in question that fakes to run Windows 9x and catches exceptions 0xC0000005 (Privileged Instruction) with some instruction decode to do the actual I/O in kernel mode. But that is time consuming and performs bad for data-acquisition software.

When I read the AMD64 manual, I detected that the TSS (Task State Segment) has the same construction as for 32-bit, and the IOPM (Input Output Permission Map) works also the same way. So it's worth investigating how Win64 TSS is implemented and whether it's possible to enable the IOPM.

Using a kernel mode debugger (windbg with a serial null-modem cable), I detected that the TSS is a per-CPU structure with 0x67 limit. Therefore it's 0x68 bytes long, the bare minimum, with no space for the IOPM. Interestingly, the IOPM pointer at offset 0x66 contains the "right" value 0x68 just beyond the limit, and the memory is filled up with zeroes at least 8 KByte for each processor's TSS. (A zero bit enables access from user mode, while one-bits will deny access. Port addresses that would result in testing bits beyond the TSS limit will also denied, therefore, the TSS limit value dictates the effective length of IOPM and the maximum allowed port address. It's common to set the TSS limit in a way to have a full 64 KBit = 8 KByte IOPM, to ease system software.)

After doing these steps, any application with inlined I/O can now execute without privilege exceptions. Most programs will complain that the driver still cannot be loaded, but that issue can be solved more easily. In some cases, you can fake the program in question to execute inlined I/O without checking the Windows version or driver first.

Now, it's time to put the solution into a functional driver. As a starting point, I used the source code of giveio.sys. However, the IOPM in 32-bit Windows is thread-specific, which is not the case for 64-bit Windows. Moreover, code had to be added to execute some piece of code on each processor. To execute specific assembly instructions, an assembly helper file was necessary because Microsoft's C compiler won't allow inline assembly for 64-bit target.

The driver itself is totally straightforward: On load, it expands the GDT's limit entry, on unload, it shrinks it to the original value. The "open" entry point is solely for compatibility to giveio.sys and dlportio.sys. Because both well-known 32-bit drivers work the same way but have different Win32 entry names, my driver simply offers two names. So either "\\.\giveio" or "\\.\dlportio" can be opened by CreateFile() with success. As stated above, nothing happens there.

The code for running code on each processor I copied out of another project, namely my USB2LPT which needed it to patch the IDT (Interrupt Descriptor Table) to catch kernel-mode I/O for redirecting. The workhorse is an array of DPC (Deferred Procedure Call) where the processor that will run the procedure can be assigned beforehand.

The latter case revealed that I forgot to reload the Task Register explicitly. A breakpoint, either hitting Ctrl+Break or a __debugbreak() macro, will reload the Task Register as a side effect of the kernel debugger. It was easy to add an str + ltr sequence, but the result was an immediate double-fault bluescreen. Reading the AMD64 manual again, it stated that ltr to a busy task will fault. Next time I deleted the busy bit out of the GDT entry, and it works:

The reason for the need of ltr (Load Task Register) is the CPU-internal cache that holds a copy of the GDT entry. Therefore, when nobody does ltr later, it's possible to revert the GDT entry to previous state, and - voil - PatchGuard won't see the hack!

I checked this out for some hours running one and another software: It really works! I'm lucky that nobody checks or overwrites the Task Register Cache value. Unfortunately, any Microsoft engineer can use this publication to include an ltr instruction into a future PatchGuard update, and - if so - that driver's functionality will die without notice. (A bluescreen won't occur.) On the other hand, a user-mode component can catch this exception and re-enable giveio.sys. Because ltr execution is time-consuming, PatchGuard cannot use it at high frequency, therefore, Microsoft cannot deny this way of port access enabling for now without a processor (hardware) update.

3a8082e126