Several causes of winio initialization failure

Winio is a database that can open some operating system I/O privileged operations. In short, it loads some drivers. The loaded driver can directly access the port. In industrial control, we can use this database to directly operate the address of the iocard. For example, I recently worked on a numerical control drilling and milling machine. The iocard and motion control card are very old cards and work normally under Win98, however, on the NT core, illegal command calling occurs. These illegal commands come from the direct address access to the iocard and motion control card at the underlying layer. In the 98 era, these operations are not protected, and protection problems may occur under the NT core. After testing, after winio initialization and loading the driver, the iocard is directly accessed.
However, some inexplicable problems occur during application. To use winio, you only need to call two functions: initializewinio () and shutdownwinio. Initializewinio () returns a bool value indicating the initialization result. This function causes a lot of troubles.
The first problem is that initialization often fails during a debugging. Once successful, the initialization always succeeds. At first, I thought it was caused by no shutdownwinioi () after initializewinio (). Later I checked the C example of winio to prove that the process can be completed once the process is completed, just like initializewinio, the resources initialized by initializewinio will naturally end. So there is no impact on the last operation. Later, we suddenly found that the DLL, VxD, and SYS related to winio were green. In Windows XP, Green indicates that files are encrypted by EFS. To keep the project confidential, I encrypted all the project directories with EFS. EFS encryption affects disk performance because of its encryption and decryption process. However, it is strange that the intermittent EFS decryption speed does not keep up with the speed of loading the driver in winio. As a result, the driver of the read sys and VxD devices is messy, which leads to loading failure. Cancel EFS encryption to solve the problem.
For the second time, I wrote a dllimport in C # And then called it. The result always returns false. I am confused. Why is it that all files related to winio are put together? In the vs2005 unit test, it will also fail. The cause is the path problem. After analyzing the source code of winio, we can find that initializewinio () calls a getdriverpath function:
Bool getdriverpath ()
{
Pstr pszslash;
If (! Getmodulefilename (getmodulehandle (null), szwiniodriverpath, sizeof (szwiniodriverpath )))
Return false;
Pszslash = strrchr (szwiniodriverpath ,'\\');
If (pszslash)
Pszslash [1] = 0;
Else
Return false;
Strcat (szwiniodriverpath, "winio. sys ");
Return true;
}
It is clear that it will be false under what circumstances. Pay attention to the location where winio. sys is stored so that it can be initialized normally.
In fact, the execution process of each step in initializewinio () can be printed in more detail, which makes it easier to determine where a problem occurs.
Write it here first. winio is a very powerful and violent library ~~~