MFAKTC won't start under RDP (win7)
 

Hi,
I'm running win7/64 (sp1) and discovered that I cannot start MFAKTC if I am using RDP to access my PC.

Nvidia driver 301.42
NvCuda.dll 4.2.1

When I try to start mfaktc I get the following error:

[B]ERROR: CUDA runtime version must match the CUDA toolkit version used during comp
ile![/B]

My attempt to work around this was to put a 15 second delay in my start-up file for mfaktc giving me time to disconnect the RDP session before program launch. Unfortunately it did not solve the problem.

Does anyone know a workaround
1. that does not require me to switch to linux
2. allows me to keep using RDP

[QUOTE=swl551;310236]Does anyone know a workaround
1. that does not require me to switch to linux
2. allows me to keep using RDP[/QUOTE]

As far as I can tell, there isn't one -- but I'd be very happy to be proven wrong. The issue, as far as I can tell, is the need for a GUI context to allow mfaktc to gain access to the GPU.

I've been fighting with this myself. SSHing into a WinBlows box and trying to launch mfaktc results in:

[CODE]CUDA version info
binary compiled for CUDA 4.20
CUDA runtime version 16711.34
CUDA driver version 5111.90
ERROR: CUDA runtime version must match the CUDA toolkit version used during compile![/CODE]

Launching a cygwin shell locally, and it works fine.

Further data... running a "scheduled task" works fine if it's set to only run when the user is logged in. But it will always fail (with the above error) if the task is set to always run -- even if the owning user is logged in!

Have I mentioned I hate WinBlows?

Not necessarily a Windows (as in Microsoft) problem; RDP works fine with AMD 5770 and 7970 and Win7 Pro. Catalyst control center complains occasionally, but Mfakto works fine.

My solution is to put a shortcut to a batch file that starts all my mfaktc instances in Windows startup folder. When I have to make changes through RDP, I just restart the computer and wait several minutes before I log back in to make sure everything is working.

[QUOTE=sdbardwick;310249]Not necessarily a Windows (as in Microsoft) problem; RDP works fine with AMD 5770 and 7970 and Win7 Pro. Catalyst control center complains occasionally, but Mfakto works fine.[/QUOTE]

Interesting.

If you (or anyone running mfakto or mfaktc) have cygwin installed, could I ask you to try this experiment?

Launch a cygwin shell, and then run the mfakt* self test. Should work fine -- kill it as soon as it reports a success.

Then "ssh localhost" from the same shell. Or else ssh in from a remote machine. Try to run the self-test again. Does it work?

Once mfaktc is kicked off - you can then RDP into the machine.

It's got to do with the driver. Tesla cards don't have that limitation. From reading around the traps - the current understanding is that RDP is a server-esque tech and the Nvidia's thinking is the product to run on a server is Tesla and not the desktop cards.

It's a way for nvidia to separate their product lines.

I suggest using an alternate remote desktop program to kick off mfaktc then rdp. Painful I know - but that's what I've been doing. I have 5 windows machines running mfaktc. I use team viewer or vnc to kick mfaktc off, but then rdp into them to see how they are going. (At the time windows8 previews didn't run vnc all that well)

RDP is still way more responsive than either vnc or teamviewer.

-- Craig

Please try LogMeIn freeware at [url]https://secure.logmein.com/[/url].

The key must be in setting the video session back to "local"
 

[QUOTE=chalsall;310243]

Further data... running a "scheduled task" works fine if it's set to only run when the user is logged in. But it will always fail (with the above error) if the task is set to always run -- even if the owning user is logged in!
[/QUOTE]

Based on the ability to launch through scheduler suggests that there is a way to "reset" the video context back to hardware and away from RDP.

I'll try a batch job that stops the RDP service, launches mfaktc and then restarts RDP.

thx for the suggestions and ideas so far.

[QUOTE=pinhodecarlos;310284]Please try LogMeIn freeware at [url]https://secure.logmein.com/[/url].[/QUOTE]

I use LogMeIn as well, works like a charm with CUDA programs.

Everything is easy if you have the right tools. An alternative is PsExec from the Sysinternals suite, downloadable at [URL="http://technet.microsoft.com/en-us/sysinternals/default"]sysinternals.com[/URL]. Be careful, that suite is not for the one having heart problems! It is very easy to totally f'up your system like in the [URL="http://forum.ebaumsworld.com/showthread.php?35082-Duck-Joke"]duck story[/URL]...

stopping/starting RDP services did not solve.
 

[QUOTE=swl551;310286]Based on the ability to launch through scheduler suggests that there is a way to "reset" the video context back to hardware and away from RDP.

I'll try a batch job that stops the RDP service, launches mfaktc and then restarts RDP.

thx for the suggestions and ideas so far.[/QUOTE]
So I setup my batch file to stop the RDP services, launch mfaktc then start RDP. Unfortunately this did not solve the problem. This tells me the abstraction layer setup for RDP is most likely managed by a kernel level API as opposed to RDP itself.

What we want to find is how to set it back. We know that logging in locally (physically) to the machine removes the abstraction layer setup for an RDP session. Maybe the answer is in gina.dll