Ticking me off, "Missing cudart.dll"

O

oraldlight

Limp Gawd
Joined
Feb 12, 2007
Messages
490
This makes no sense:

Vista 32, 6.20 cpu client, no overclocking or SMP
I am running a 260gtx +GPU without issue(180.43 driver)

About last Friday, my cpu client crashed and was just realized. Attempts to resolve are going unproductive. It claims "Missing cudart.dll" which I trace back to a Nvidia DLL. But for the CPU client??

From Vista:
Problem signature:
Problem Event Name: APPCRASH
Application Name: FahCore_11.exe
Application Version: 0.0.0.0
Application Timestamp: 490f3633
Fault Module Name: cudart.dll
Fault Module Version: 6.0.6000.16386
Fault Module Timestamp: 4549bdc9
Exception Code: c0000135
Exception Offset: 00008fc7
OS Version: 6.0.6000.2.0.0.256.6
Locale ID: 1033
Additional Information 1: 9d13
Additional Information 2: 1abee00edb3fc1158f9ad6f44f0f6be8
Additional Information 3: 9d13
Additional Information 4: 1abee00edb3fc1158f9ad6f44f0f6be8
Click to expand...

From FAHmon:
[23:00:13] - Ask before connecting: No
[23:00:13] - User name: oraldlight (Team 33)
[23:00:13] - User ID: (redacted)
[23:00:13] - Machine ID: 1
[23:00:13]
[23:00:13] Loaded queue successfully.
[23:00:13] Initialization complete
[23:00:13]
[23:00:13] + Processing work unit
[23:00:13] Core required: FahCore_11.exe
[23:00:13] Core found.
[23:00:13] Working on queue slot 05 [November 18 23:00:13 UTC]
[23:00:13] + Working ...
[23:01:25] CoreStatus = C0000135 (-1073741515)
[23:01:25] Client-core communications error: ERROR 0xc0000135
[23:01:25] This is a sign of more serious problems, shutting down.
Click to expand...


I've tried uninstalling, reinstalling, deleting "fahcore11.exe", deleted my patially completed work folder, I give up.

Any one got an idea for resolution? My XP64+32 CPU clients are identical and no problems.


 
Try:
Check to see if Cudart.dll is in your FAH directory. example (C:\Users\Admin\AppData\Roaming\Folding@home-gpu)
If it is then continue. If not do a search and find it.
Go to System from Control Panel.
Select Advanced system settings.
Select Advanced Tab.
Select Environment Variables button at bottom.
Under System variables windows highlight the variable Path.
Select edit button to edit variable Path.
Add to the end of variable value ;(location to FAH directory or location to were cudart.dll was found from search) be sure to start it with a semicolon.
example (;C:\Users\Admin\AppData\Roaming\Folding@home-gpu)
Click on OK on screens until back to System window. Close window. Reboot.
Try FAH now. Hope this helped.

 
IMHO, you need to wipe the client folder completely from both places then reinstall it from scratch. cudart.dll is in the program files folder and somehow, it got borked.

 
Xilikon gets the tamale and beer.
Manual delete of both folders and reinstalled. Recreated config file (rather than recycle form prior) and now I'm productive.

Nothing like a rant to make a fool of yourself to find the obvious.

Razor_FX_II: A shot of Tequila for you. Vista Search function found NO TRACE of that file anywhere on PC. Makes me wonder if the search function is really looking at all the nooks and cranies or not.

Thanks folks, I'm folding more Amber units now..woohoo 15 points!!



 
Glad to hear it works fine now. thanks for the warm beer and cold tamales (or it is cold beer and warm tamales ?).

Fold on !

 
Xilikon said:
Glad to hear it works fine now. thanks for the warm beer and cold tamales (or it is cold beer and warm tamales ?).

Fold on !

Click to expand...

Tamales are like women - The hotter, the more memerable.
Beer is good! Duf is the best! - Homer


 
oraldlight said:
Tamales are like women - The hotter, the more memerable.
Beer is good! Duf is the best! - Homer


Click to expand...

And, if all else fails go to the CUDA page and download “tools”. That is the down and dirty fix;)

 
Well, I don't understand why it's back, but it is.
This application has failed to start because cudart.dll was not found.
Re-installing the applciation may fix this problem.
Click to expand...

As best I can tell, the work unit completed last night (of course while I was asleep).
CPU Client won't open so I have to trust the log file whichy reports the following:
Completed 1500000 out of 1500000 steps (100%)
Writing final coordinates.
Past main M.D. loop

Finished Work Unit:
- Reading up to 188856 from "work/wudata_07.arc": Read 188856
- Reading up to 34696 from "work/wudata_07.xtc": Read 34696
goefile size: 0
logfile size: 26255
Leaving Run
- Writing 256811 bytes of core data to disk...
Done: 256299 -> 225842 (compressed to 88.1 percent)
... Done.
- Shutting down core

Folding@home Core Shutdown: FINISHED_UNIT
Click to expand...

I fail to understand why the CPU client is looking for a video DLL. Anyone want to try trouble shootign thsi before I re-install AGAIN.
Vista Business 32bit, FahCore_11.exe, NV180.43+260gtx+6.20r1=working just fine. [3rd PC in sig]
 
cudart.dll is required to have the client communicate with the video card via CUDA.

Your explanation is a bit cryptic so I will ask you the exact setup of the various clients in this computer and if possible, a screenshot of the files included in the Program Files client folder.

 
oraldlight said:
I fail to understand why the CPU client is looking for a video DLL. Anyone want to try trouble shootign thsi before I re-install AGAIN.
Vista Business 32bit, FahCore_11.exe, NV180.43+260gtx+6.20r1=working just fine. [3rd PC in sig]
Click to expand...

FahCore_11.exe is the GPU core.
FahCore_a1.exe & FahCore_a2.exe are the two SMP cores.
Anything else is a standard client core.

If you are calling FahCore_11.exe then you are running the GPU client.
Hence it's looking for the video DDL.

Which client did you think you where running ??

Luck ............... :D
 
Oh masterfull, Xilikon, I realize your questions value but have no means of posting images at this moment.

I run, on that pc, both one CPU client(no SMP, no VM) and a GPU client under Vista Business 32bit. The GPU client runs fine. The CPU client is my trouble of late.
GPU 6.20r1, + NVidia 180.43 driver
CPU 6.20
AMD x2-5000, PNY 260gt

Last time, I ended up re-installing (from a fresh download) the CPU client and was running without issues until last night. From what I can see, a WU finished, uploaded - and this is where it gets fuzzy - it may or may not have gotten another WU. Attempts to reboot and/or restart were met with the prior "Missing cudart.dl" message. While the GPU was happy and still running, the CPU would fail to start with Windows offering to send the info back to Redmond.

On a whim this morning, I copied the whole folder under "C:\Users\oraldlight\AppData\Roaming\Folding@home-x86", for 'insurance'.
I then deleted from the originalfolder, the work folder contents(current.xyz, wudata_08.dat, logfile_03.txt, logfile_07.txt ), queue.dat, unitinfo.txt, fahlog.txt, and tried restarting. A few "unable to connect to 171.64.65.65" attempts and now it's up and working. I am inclined to believe there is a rougue WU since this was such a WU focused effort and was successful.

Since I have a duplicate of the prior, "missing cudart.dll" scenario. I could try swapping in/out single files to whittle this down to find the cause. I'm a bit confused on this as DLL suggests this is a GPU issue, yet it is the CPU client that files. I've searched the C;/ and there is NO "cudart.dll". This is confusing to me.
 
Maybe you are confusing the client packages instead. The GPU client and CPU client indeed do share the same version numbering and possibly the same look. Double-check that you got the right client packages ;)

However, if it is working well, it might be some client code hiccup.

 
The "cudart.dll" file is in your GPU clients data folder.

From the look of things, the CPU short-cut is calling the GPU client program but still looking in the CPU data folder.
Hence starting FahCore_11.exe which is the GPU client core and not finding cudart.dll which is in the GPU data folder.
I'd double check the CPU short-cut is targeting the right program folder.

Luck .............. :D
 
Double checked and accurate.
Note, the CPU client WAS running prior to this latest glitch.

You're right, I see cudart.dll in the GPU folder. I wonder why Windows search didn't see it .hmm....

However, the naming of thes folders is close: Folding@home-gpu vs. Folding@home-x86
 
Seems I owe Tigerbiten a cookie - he done 'learned' me a new piece of info. Seems I was not aware of Vista's preference to search 'common' files and not the "all inclusive, DLL, shidden files, etc... " I'm accustomed to.
 
oraldlight said:
Double checked and accurate.
Note, the CPU client WAS running prior to this latest glitch.

You're right, I see cudart.dll in the GPU folder. I wonder why Windows search didn't see it .hmm....

However, the naming of thes folders is close: Folding@home-gpu vs. Folding@home-x86
Click to expand...
I would try my suggestion I posted earlier in this thread.

 
Razor_FX_II said:
I would try my suggestion I posted earlier in this thread.
Click to expand...

I don't think it will make any difference in fixing the problem.
Its the CPU client thats starting the GPU core, which is why its looking for the cudart.dll file.
If that worked all that would happen would be to get both the CPU & GPU clients running on the video card.

In the CPU folders that you moved, is there a FahCore_11.exe file.
If not, which FahCore's are there ??
I'm trying too work out when it glitches is it calling the GPU client straight, in which case the FahCore_11 will only be in the GPU folder, or is it downloading the FahCore_11 into the CPU folder to run from ??

Was the GPU client running all the time ??
One thing to try next time it gliches is to shut both clients down.
Then try starting the CPU client first and only once thats runninhg ok, start the GPU.

Are they both systray clients ??
If they are you could try running one systray client and console client and see if that stops the glitches.

One other thing, You could try renaming both program folders.
Folding@home-gpu -> Graphics-Folding-Program.
Folding@home-x86 -> CPU-Folding-Program.
Then remake the two shortcuts.
Don't think that will make any difference but you never know with Windoze.

Luck ............ :D
 
Tigerbiten said:
I don't think it will make any difference in fixing the problem.
Its the CPU client thats starting the GPU core, which is why its looking for the cudart.dll file.
If that worked all that would happen would be to get both the CPU & GPU clients running on the video card.

In the CPU folders that you moved, is there a FahCore_11.exe file.
If not, which FahCore's are there ??
I'm trying too work out when it glitches is it calling the GPU client straight, in which case the FahCore_11 will only be in the GPU folder, or is it downloading the FahCore_11 into the CPU folder to run from ??
Click to expand...
FahCore's 11, 13 exist in the GPU folder.
FahCore's 11, 78, 81 exist in the CPU folder

All installs are default location. I copied, not moved, the broken CPU folder this morning for sake of having something to go back to (for detective work).

I'm inclined to agree that this appears to be some cross-reference issue here. Could it be a memory allocation issue? Or is it more likley the nearly-same name folders issue. I can't be the only one suffering this, am I?
Strange how it happens upon completion of WU/start of next WU. Deleting the work is not the answer, but one of the *.txt or *.dat fioles may hold the clue.
Was the GPU client running all the time ??
One thing to try next time it gliches is to shut both clients down.
Then try starting the CPU client first and only once thats runninhg ok, start the GPU.
Click to expand...
GPU is/was/still is running without issue.
Sequence of starting made no difference. Even a reboot did not help.

Are they both systray clients ??
If they are you could try running one systray client and console client and see if that stops the glitches.
Click to expand...
No Console clients, only systrays for both CPU adn GPU.

One other thing, You could try renaming both program folders.
Folding@home-gpu -> Graphics-Folding-Program.
Folding@home-x86 -> CPU-Folding-Program.
Then remake the two shortcuts.
Don't think that will make any difference but you never know with Windoze.
Click to expand...
Thought about that, but am resisting until we can sort this out and save others the hassle of this glitch. [Don't expect it to matter either.]
Luck ............ :D
Click to expand...


 
I'm from the old DOS days and if any prog is trying to find a file and can't, all you need to do is put a Path=(where that file is) in your Environment string and reboot.
Problem fixed. It doesn't matter what prog is calling, if its in the path Windows knows where to find it. Have done it with so many things I can't even count.
Had friends copying their entire EverQuest directories into the My Document folders to get EQ to run right. (well thats because My Documents is in the Path string).
Showed them how to simply put the EQ folder in the path string and bingo, problem fixed.

 
With the GPU client still running can you remove the FahCore11 in the cpu client folder? If it doesn't let you remove it then I'd redo your gpu shortcut.



 
tkam said:
With the GPU client still running can you remove the FahCore11 in the cpu client folder? If it doesn't let you remove it then I'd redo your gpu shortcut.
Click to expand...

FahCore_11.exe in the CPU folder is able to be deleted. It restores (magicaly) upon startign of the CPU client via the start menu. I've not looked closely at the GPU folder since it was runnign without issues.

I've triple checked all shortcuts and they are correct, so it's not a typo. Besides, this WAS running when it happened, so it started fine. Ran for about a week+wihtout issues.

+++
Razor - I hear you on that point. I'm hesitant about it because it is "too easy" a fix. I would like to think this would of sufaced sooner (like the install or at boot time). Besides, why would it loose the path in the middle of a run? That I left the shortcuts alone and dumped the work unit info, makes me think this is WU related problem.

As if, somehow, that CPU WU is really a GPU WU. If anyone knows how to decrypt the info of wudata_08.dat, we may be able to see what/where/why.

 
queue.dat contain the infos about the workunits. At slot 8 in your queue.dat, the WU is P5506R8C770G131 which is a nvidia GPU unit so if what you said is exact, it's a bad assignment issue. I'll poke the FCF and the PG to see if this can happen or if it it's a AS hiccup.

 
oraldlight said:
Razor - I hear you on that point. I'm hesitant about it because it is "too easy" a fix. I would like to think this would of sufaced sooner (like the install or at boot time). Besides, why would it loose the path in the middle of a run? That I left the shortcuts alone and dumped the work unit info, makes me think this is WU related problem.
Click to expand...
It could be from the way your logged in, or could be that something out of the ordanary has been done with User profiles, could be acouple seconds to try and see it it works.
It is totally reversable, at least if it works it can eliminate so many other possable reasons as to what is causeing it and may lead you to the actual cause sooner.
Just be sure to reboot after you add where the file is at to your Path.
You think just because I give you a "too easy" of a fix that it's not what you may need?
I have been in the computer repair and networking administration profession for going on 25 years.
Worked for plenty of repair shops, IT departments and owned my own computer sales, repair and network administration buisness for many years.
I wouldn't have you try something that I didn't think would work or at least lead you down the right path.

Edit: Could be that your trying to run the GPU2 from a pin to start menu or a shortcut ito a Vista Sidebar plugin. If you are doing that - you must create a shortcut to the exacutable first and then pin the shortcut, and use this shortcut in any Vista Sidebar plugins.
 
I made a thread in a private section about that issue and Vijay personnally replied to mention that both clients look at completely different Assignation Servers so the only explanation is a bad configuration (clients mixing data folders and sharing files together). This reinforce my suggestion to wipe your box of any F@H trace then reinstall it carefully or to get 2 console clients (both set for service mode).

 
Razor_FX_II - I think I said it poorly. I did not mean to offend you. You are right and I will try.

I heard back for another source who is re-afirming that it sounds like an install problem as well.

I'll set the clients to stop after completion (so I can finish the WU's) and uninstall, reinstall both clients. I'll also try adding the environmenta variable paths

 
oraldlight said:
Razor_FX_II - I think I said it poorly. I did not mean to offend you. You are right and I will try.

I heard back for another source who is re-afirming that it sounds like an install problem as well.

I'll set the clients to stop after completion (so I can finish the WU's) and uninstall, reinstall both clients. I'll also try adding the environmenta variable paths

Click to expand...
Oh please don't get me wrong. You didn't offend me, just trying to put a little credibility behind my suggestion.
I just have my troubleshooting ways. Everyone has a differant approach. Just trying to narrow things down in my own head with my simple quick test to see if it a naming/directory/shortcut problem. If the Path variable works then it is.
If my Path trick doesn't work then there is something else going on.

 
Alright now... Upon re-installation, which does not allow alternate locations, and a reboot prior to going through config, I was greeted with the startup shortcuts (that I overlooked) firing up both CPU and GPU systray clients. As I started filling in details and checking off tick boxes, I mindlessly allowed the machine ID to BOTH point to #2 - DOH!

Quick check of the prior configs showed me that, yup, somehow overlooked that one.

I've implemented Razor's suggested environment variable tweak as well, just for good measure.

Seems I owe a few people some beers for showing me the nearly obvious.

 
oraldlight said:
I mindlessly allowed the machine ID to BOTH point to #2 - DOH!
Click to expand...
That reminds me of when I turned in a SMP unit and didn't seem to get any points for it.
After getting verification that the unit was infact turn in and I was credited the points, I checked fah-web.stanford.edu stat site to learn that the WU point went to team #3 instead of #33.
DOH! Didn't hit that key twice when I was running through the SMP config file.
Learned when it comes to config's I need to slow myself down.

 
You must log in or register to reply here.
Back
Top