Project 10001 - ERROR 0x3

[Bob8421]

This morning I started receiving new work units for project 10001 and new core b4. One of the clients only got as far as the log message "Digital signatures verified" before a message box appeared offering to send an error report to Microsoft. The message was "FahCore_b4.exe has encountered a problem and needs to close." After responding to this box, the log file continued with:

CoreStatus = 3 (3)
Client-core communications error: ERROR 0x3
This is a sign of more serious problems, shutting down.

Restarting the client produced the same results. Then I deleted the new core and restarted the client, but the newly downloaded core again produced the same results. Then I deleted the work unit and restarted the client, but the newly downloaded work unit again produced the same results. I have 3 other instances of project 10001 running successfully, one on the same computer as the problem and two on other computers.

What is ERROR 0x3 and how do I fix it?

[tonic]

Been getting this one on the 10001 Projects randomly as well. This is with the Linux 6.02 Uni client. I've had a bunch complete successfully though as well, so I'm not really sure what's going on.

[Pette Broad]

Yes, there are a few of these units that are causing problems. The solution I used was to delete the unit then remove the -advmethods flag and restart the client.


Pete

[toTOW]

What CPU ? Which OS ? 32 or 64 bits ? ...

[MtM]

toTow this is what I ment on msn, I send Joseph a pm about it just a moment ago ( with no links to this thread as I hadn't seen it yet ).

This needs a server fix.

@Bob

Then I deleted the work unit and restarted the client, but the newly downloaded work unit again produced the same results.

Go to your clients folder, delete the work folder and machinedependant.dat, restart the client. You should get a new wu now ( but you will have to repeat this if you get stuck with another bad wu ).

[Bob8421]

Windows XP Home on Intel Q6600 CPU.

I deleted the work unit once, but the next one to download caused the same problem and I didn't continue deleting them to see if I would get one to work. Since someone mentioned that this was an occasional problem, I deleted the work unit one more time, but again I received a new one that caused the same problem.

Only one of the three work units that failed produced the additional 3 lines in the log and then stopped right there. The other two produced an additional Windows message box and replying to that then caused the client to shut down.

I have since received additional project 10001 work units in other clients and all are working properly.

[MtM]

On windows there is no machinedependant.dat, if you get stuck with getting the same wu more then 6 times you could try regedit -> search for Stanford, export key for backup, delete key -> restart client. This will generate a new clientID so the server will not send you the bad wu again.

[7im]

Deleting the work folder and queue.dat file a couple times is usually safer.

[Bob8421]

I've deleted the work folder for that client at least half-a-dozen times, but the new work unit always has the same problem. I just now tried deleting the queue.dat file also, but that didn't change anything.

I have two identical Q6600 systems, and thus 8 clients, all of which were set up exactly the same a long time ago. In addition to the problem client, there are 3 other clients on those systems running project 10000 and 10001 without any issues (so far). Also an old Athlon X2 client is just fine running 10000 using v5.04 on Windows 2000.

It doesn't make much sense to keep deleting work units hoping that something will change, but I have no idea what else to do.

[Dekar12]

Came home this afternoon and this error was on my screen, I saw here that deleting the work folder had fixed this error for another user so I did that as well. The log below is after I deleted the work folder.

I have been running a single client on this machine for over 6 months now with no errors. Any suggestions?

Code: Select all

# Windows CPU Console Edition #################################################
###############################################################################

                       Folding@Home Client Version 6.23

                          http://folding.stanford.edu

###############################################################################
###############################################################################

Launch directory: C:\Users\Dekar\Documents\Folding
Executable: C:\Users\Dekar\Documents\Folding\Folding@home-Win32-x86.exe
Arguments: -advmethods 

[22:03:36] - Ask before connecting: No
[22:03:36] - User name: Dekar (Team 33)
[22:03:36] - User ID: 7489737E64CB4B35
[22:03:36] - Machine ID: 1
[22:03:36] 
[22:03:36] Work directory not found. Creating...
[22:03:36] Loaded queue successfully.
[22:03:36] 
[22:03:36] + Processing work unit
[22:03:36] Core required: FahCore_b4.exe
[22:03:36] Core found.
[22:03:36] Working on queue slot 06 [December 22 22:03:36 UTC]
[22:03:36] + Working ...
[22:03:39] *********************** Log Started 22/Dec/2009 22:03:39 ***********************
[22:03:39] ************************** ProtoMol Folding@Home Core **************************
[22:03:39]   Version: 19
[22:03:39]      Type: 180
[22:03:39]      Core: ProtoMol
[22:03:39]   Website: http://folding.stanford.edu/
[22:03:39] Copyright: (c) 2009 Stanford University
[22:03:39]    Author: Joseph Coffland <joseph@cauldrondevelopment.com>
[22:03:39]      Args: -dir work/ -suffix 06 -checkpoint 15 -lifeline 2520 -version 623
[22:03:39] ************************************ Build *************************************
[22:03:39]      Date: Dec 16 2009
[22:03:39]      Time: 17:02:04
[22:03:39]  Revision: 1746
[22:03:39]  Compiler: Intel(R) C++ MSVC 1500 mode 1110
[22:03:39]   Options: /TP /nologo /EHsc /wd4297 /wd4103 /wd1786 /arch:IA32 /Ox
[22:03:39]            /QaxSSE2,SSE3,SSSE3,SSE4.1,SSE4.2 /Qrestrict /MT
[22:03:39]  Platform: Windows XP
[22:03:39]      Bits: 32
[22:03:39] ************************************ System ************************************
[22:03:39]        OS: Microsoft Windows 7 Ultimate
[22:03:39]       CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
[22:03:39]    CPU ID: GenuineIntel Family 6 Model 26 Stepping 5
[22:03:39]      CPUs: 16 Logical, 1 Physical
[22:03:39]    Memory: 5.99 GB
[22:03:39] ********************************************************************************
[22:03:39] ERROR: @ fah\os\SystemUtilities.cpp:437:<unknown> 117: Failed to open '../wudata_06.dat': Failed to open '../wudata_06.dat': No such file or directory
[22:03:39] Folding@home Core Shutdown: FILE_IO_ERROR
[22:03:43] CoreStatus = 75 (117)
[22:03:43] Error opening or reading from a file.
[22:03:43] Deleting current work unit & continuing...
[22:03:49] - Preparing to get new work unit...
[22:03:49] + Attempting to get work packet
[22:03:49] - Connecting to assignment server
[22:03:49] - Successful: assigned to (129.74.85.48).
[22:03:49] + News From Folding@Home: Welcome to Folding@Home
[22:03:50] Loaded queue successfully.
[22:03:50] + Closed connections
[22:03:55] 
[22:03:55] + Processing work unit
[22:03:55] Core required: FahCore_b4.exe
[22:03:55] Core found.
[22:03:55] Working on queue slot 07 [December 22 22:03:55 UTC]
[22:03:55] + Working ...
[22:03:57] *********************** Log Started 22/Dec/2009 22:03:57 ***********************
[22:03:57] ************************** ProtoMol Folding@Home Core **************************
[22:03:57]   Version: 19
[22:03:57]      Type: 180
[22:03:57]      Core: ProtoMol
[22:03:57]   Website: http://folding.stanford.edu/
[22:03:57] Copyright: (c) 2009 Stanford University
[22:03:57]    Author: Joseph Coffland <joseph@cauldrondevelopment.com>
[22:03:57]      Args: -dir work/ -suffix 07 -checkpoint 15 -lifeline 2520 -version 623
[22:03:57] ************************************ Build *************************************
[22:03:57]      Date: Dec 16 2009
[22:03:57]      Time: 17:02:04
[22:03:57]  Revision: 1746
[22:03:57]  Compiler: Intel(R) C++ MSVC 1500 mode 1110
[22:03:57]   Options: /TP /nologo /EHsc /wd4297 /wd4103 /wd1786 /arch:IA32 /Ox
[22:03:57]            /QaxSSE2,SSE3,SSSE3,SSE4.1,SSE4.2 /Qrestrict /MT
[22:03:57]  Platform: Windows XP
[22:03:57]      Bits: 32
[22:03:57] ************************************ System ************************************
[22:03:57]        OS: Microsoft Windows 7 Ultimate
[22:03:57]       CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
[22:03:57]    CPU ID: GenuineIntel Family 6 Model 26 Stepping 5
[22:03:57]      CPUs: 16 Logical, 1 Physical
[22:03:57]    Memory: 5.99 GB
[22:03:57] ********************************************************************************
[22:03:57] Project: 10001 (Run 855, Clone 4, Gen 0)
[22:03:57] Reading tar file par_all27_prot_lipid.inp
[22:03:57] Reading tar file scpismQuartic.inp
[22:03:57] Reading tar file ww_exteq_nowater1.pdb
[22:03:57] Reading tar file ww_exteq_nowater1.psf
[22:03:57] Reading tar file protomol.conf
[22:03:57] Reading tar file core.xml
[22:03:57] Digital signatures verified
[22:04:11] CoreStatus = 3 (3)
[22:04:11] Client-core communications error: ERROR 0x3
[22:04:11] This is a sign of more serious problems, shutting down.

[uncle fuzzy]

The suggestion was to delete the work folder AND the queue.dat file.

This is the brute force, last ditch effort to clear a bad WU out of your client.

[Dekar12]

The suggestion was to delete the work folder AND the queue.dat file.

This is the brute force, last ditch effort to clear a bad WU out of your client.

Sorry, meant that I deleted the queue.dat file as well and still got that error message.

[uncle fuzzy]

You might also want to delete the core, in case IT has the problem.

[Dekar12]

I dropped out the "-advmethods" from my client and it appears to be grabbing normal work units fine.

Looks like the "ProtoMol" that it grabbed did not work well with my machine/client or something.

[bruce]

I dropped out the "-advmethods" from my client and it appears to be grabbing normal work units fine.

Looks like the "ProtoMol" that it grabbed did not work well with my machine/client or something.

Many folks add the -advmethods flag without a second thought although it does signify a willingness to accept this sort of problem from time to time. Removing the flag is the right answer.

I've seen this error and development is aware of it but we may not see a fix immediately. In some cases, I've been able to restart the WU from the last checkpoint and it proceeds to 100% without difficulty. There are reports saying the opposite is true. YMMV.