Error: Could not load transport DLL s80trans.dll

[windbag]

In recent weeks, I've been getting message:

Could not load transport DLL s80trans.dll

I'm using a Space Navigator in Vista 32, fully up date.
Just rechecked installation/validated/repaired current version [3.15.3, driver 6.15.3, Firmware 3.18], & just enabled Log file - it says:

UdCtl: Could not load transport DLL: s80trans.dll. Error=0x1e7

Done some forum searching; tried making exceptions in AVGfree for both main executable (3dxsrv.exe) and the s80trans.dll - no difference.

Tried running 3dxsrv.exe as admin - no difference.

Lights do work and it does work in Google Earth 6.1.0.5001
Do sometimes get "device unrecognised" after waking from "sleep".

Suggestions welcome.

[windbag]

Should have said:

The offending s80trans.dll IS in place in the file structure, and, if clicked on, says the driver is already running, so seems intact/working.

[Fred]

The error "Could not load transport DLL s80trans.dll" occurs when there is either another program is using the file s80trans.dll or an anti-virus application is blocking it.

To resolve the error " Could not load transport.." you will need to determine what it is on your system that is blocking the .dll from being able to load.. One type of application known to interfere in this way is programs that configure your standard mouse such as the MouseImp program. Once you determine the conflicting program you can turn off the program and re-install the 3Dconnexion software. Once that is completed and you can use the 3Dconenxion software without the error, you can typically turn back on the conflicting program since it is most often the order they load in that is causing the error..

If you are not sure which of the background applications may be causing the problem, Microsoft has 'clean startup' steps here : http://support.microsoft.com/kb/331796

The other type of application that causes this type of .dll error is anti-virus/spyware applications. If this is a personal PC it is best to disconnect from the internet then turn all of the security software to complete the installation. On a network PC , IT help will be needed to create an exception for the 3Dconnexion software executable 3dxsrv.exe

Some issues of this type can be corrected by using an additional level of permissions when running the 3Dconnexion installation. In addition to installing from an administrator profile , right-click on the downloaded 3dxsoftwarexxx.exe and choose 'Run as adminsitrator'

One other thing since it appears you are working in some applications is to make sure the devicie is plugged into the usb port not using a hub or monitor, they donot always provide enough power to correctly detect the device.

[Lanqu]

Hey,
Can you check if that file is present on the filesystem?
Also try to find, if there are any un-english words in system path... That can influence as well

[windbag]

To reply to both:

..Microsoft has 'clean startup' steps here : http://support.microsoft.com/kb/331796

I did try that, and it highlighted a couple of Creative startups that I'd hoped were long gone (now disabled), but little else that I wasn't expecting.

The best clue was:

One type of application known to interfere in this way is programs that configure your standard mouse such as the MouseImp program.

I have installed a program called Soluto (actually quite useful), one part of which is focussed on minimising boot-up times by removing or delaying startup items. I'd delayed 3dconnexion startup, as I never need to use 3d immediately on bootup, but I do use WizMouse to enable windows focus to follow where the mouse points and rely on it operating straight away.

So, I guessed it was that running before 3dx that was fouling up s80trans.dll

To save (quite a lot of) my time, I mainly put the PC into sleep after each day, rather than rebooting - so I've only just done a full reboot - and the dll load error didn't come up - so it looks like that was the problem.

a final bit:
I do try & put a fair amount of detail in my questions so as to not waste people's time, so the suggestion to check whether the dll file was 'present on the filesystem' was disappointing, as I'd already said I'd checked the dll file was there. And no, there were no un-english words in the filepath - I'd certainly have mentioned that if there had been!