The actions of this driver cause malfunction in the system of drivers' cooperation. The architecture of drivers function within the operation system is the following: the system has Driver Objects and Device Objects. Each driver creates Device Object for the device it belongs to. Each Driver Object has a list of Device Objects which it created and served. Each Device Object has a link to Driver Object the device belongs to. All of these are controlled by core?s subsystem Object Manager. It is only through the Object Manager the objects are created and removed.
Most likely the SunComm driver is a driver for mass-storage controllers such as: IDE/SCSI/SATA/RAID etc.
The conflict occurs when SbcpHid driver sets aside memory within the operation system, copies into this memory the Driver Object of the mass-storage controller driver and adds changes necessary for its own proper functionality.
As the result the system receives a false object. The Object Manager carries no information about it because the object was never actually created. Then the driver substitutes links of the mass-storage controller in the Device Object for a new non-existant Driver Object. Since these links used to refer to the real Driver Object these actions cause a conflict in the architecture of the operation system because a situation occurs when some Device Objects refer to a fake, non-existent Driver Object.
As the result the user suffers from SunComm system malfunction because the activation of SbcpHid driver creates compatibility problems with other drivers in the system.
SunComm prompts users to contact the StarForce support service for specific information about drivers' compatibility.