1073741205 Error Code (Unknown Error)

Message boards : Number crunching : 1073741205 Error Code (Unknown Error)
Message board moderation

To post messages, you must log in.

1 · 2 · 3 · 4 . . . 6 · Next

AuthorMessage
James W

Send message
Joined: 26 May 12
Posts: 51
Credit: 4,956,027
RAC: 13
United States
Message 1791217 - Posted: 28 May 2016, 8:09:42 UTC

This evening I noticed that over the last 24 hours I had 5 of my SETI@home v8 v8.00 windows_intelx86 WUs error out, each with same error. "Exit status -1073741205 (0xffffffffc000026b) Unknown error number." Shown in Stderr output as "(unknown error) - exit code -1073741205 (0xc000026b)." At least one other person using same app got same error in these 5 WUs. These were all on my Windows 7 machine.

Has this been an issue for others using this app?
ID: 1791217 · Report as offensive
Profile janneseti
Avatar

Send message
Joined: 14 Oct 09
Posts: 14106
Credit: 655,366
RAC: 0
Sweden
Message 1791218 - Posted: 28 May 2016, 8:24:50 UTC - in response to Message 1791217.  
Last modified: 28 May 2016, 8:27:08 UTC

This evening I noticed that over the last 24 hours I had 5 of my SETI@home v8 v8.00 windows_intelx86 WUs error out, each with same error. "Exit status -1073741205 (0xffffffffc000026b) Unknown error number." Shown in Stderr output as "(unknown error) - exit code -1073741205 (0xc000026b)." At least one other person using same app got same error in these 5 WUs. These were all on my Windows 7 machine.

Has this been an issue for others using this app?

It's a BOINC error. There are more BOINC projects that get this error.
https://www.google.se/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=0xffffffffc000026b
ID: 1791218 · Report as offensive
atlov

Send message
Joined: 11 Aug 12
Posts: 35
Credit: 32,718,664
RAC: 34
Germany
Message 1791223 - Posted: 28 May 2016, 9:15:51 UTC
Last modified: 28 May 2016, 9:18:18 UTC

Yeah, sounds familiar to me. Thanks for the google link, James. I think all these hosts have one thing in common: Windows 7.
ID: 1791223 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14645
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1791224 - Posted: 28 May 2016, 9:18:21 UTC - in response to Message 1791218.  
Last modified: 28 May 2016, 9:22:49 UTC

Actually, it's a Microsoft error. Work off the stderr version of the error code (0xc000026b), ignoring BOINC's "room for expansion" extra 32 bits of FFFFFFFF.

From NTSTATUS values:

0xC000026B
STATUS_DLL_INIT_FAILED_LOGOFF
{DLL Initialization Failed}

The application failed to initialize because the window station is shutting down.

I guess that means that BOINC and Windows are fighting over the task: BOINC is trying to start it up, and Windows is trying to shut it down.

Solution - well, workround: shut down BOINC before shutting down Windows.
ID: 1791224 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1791407 - Posted: 28 May 2016, 18:35:04 UTC - in response to Message 1791224.  

I guess that means that BOINC and Windows are fighting over the task: BOINC is trying to start it up, and Windows is trying to shut it down.

Solution - well, workround: shut down BOINC before shutting down Windows.

Yes, it does seem that Windows is trying to shut down the individual task processes before BOINC gets the shutdown notification, or at least before BOINC acts on it, so it doesn't seem to know why the tasks have stopped running (i.e., "exited with zero status but no 'finished' file") and then tries to restart them.

The thing is, why does this seem to be a relatively new phenomenon? As I mentioned in my posts over in atlov's thread, I've been able to identify occurrences back to last December, but only with BOINC 7.6.9 and 7.6.22. Also, I've only seen it on Windows 7 and Windows 8.1, although the two occurrences I've found on 8.1 didn't result in errors.

In fact, most of the occurrences don't actually result in errors, and I've not yet had the time to try to figure out if there's a common denominator in the ones that do. The Event log snippet from my daily driver that I posted in that other thread didn't result in errors. On the other hand, the following mess is from one that actually resulted in 5 error tasks, even though only 3 tasks (2 CPU, 1 GPU) were running at the time of the shutdown (which was a Windows Update restart, thus likely interfering with other processes during the 6 seconds it took to shutdown).

27-Apr-2016 21:30:55 [SETI@home] Started upload of 17mr10aa.19592.25024.13.40.19_0_0
27-Apr-2016 21:30:57 [SETI@home] Finished upload of 17mr10aa.19592.25024.13.40.19_0_0
27-Apr-2016 22:03:36 [SETI@home] Task 18mr10aa.16813.9883.3.30.98_1 exited with zero status but no 'finished' file
27-Apr-2016 22:03:36 [SETI@home] If this happens repeatedly you may need to reset the project.
27-Apr-2016 22:03:36 [SETI@home] Task blc3_2bit_guppi_57451_26692_HIP69732_OFF_0024.9984.831.17.26.89.vlar_1 exited with zero status but no 'finished' file
27-Apr-2016 22:03:36 [SETI@home] If this happens repeatedly you may need to reset the project.
27-Apr-2016 22:03:36 [SETI@home] Task 17mr10aa.19592.25024.13.40.10_1 exited with zero status but no 'finished' file
27-Apr-2016 22:03:36 [SETI@home] If this happens repeatedly you may need to reset the project.
27-Apr-2016 22:03:36 [SETI@home] [cpu_sched] Restarting task 18mr10aa.16813.9883.3.30.98_1 using setiathome_v8 version 800 in slot 1
27-Apr-2016 22:03:36 [SETI@home] [cpu_sched] Restarting task blc3_2bit_guppi_57451_26692_HIP69732_OFF_0024.9984.831.17.26.89.vlar_1 using setiathome_v8 version 800 in slot 2
27-Apr-2016 22:03:36 [SETI@home] [cpu_sched] Restarting task 17mr10aa.19592.25024.13.40.10_1 using setiathome_v8 version 800 (cuda50) in slot 0
27-Apr-2016 22:03:38 [SETI@home] Task 17mr10aa.19592.25024.13.40.10_1 exited with a DLL initialization error.
27-Apr-2016 22:03:38 [SETI@home] If this happens repeatedly you may need to reboot your computer.
27-Apr-2016 22:03:38 [SETI@home] Computation for task 18mr10aa.16813.9883.3.30.98_1 finished
27-Apr-2016 22:03:38 [SETI@home] Computation for task blc3_2bit_guppi_57451_26692_HIP69732_OFF_0024.9984.831.17.26.89.vlar_1 finished
27-Apr-2016 22:03:38 [SETI@home] [cpu_sched] Restarting task 17mr10aa.19592.25024.13.40.10_1 using setiathome_v8 version 800 (cuda50) in slot 0
27-Apr-2016 22:03:38 [SETI@home] Starting task blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.20612.0.17.26.187.vlar_1
27-Apr-2016 22:03:38 [SETI@home] [cpu_sched] Starting task blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.20612.0.17.26.187.vlar_1 using setiathome_v8 version 800 in slot 1
27-Apr-2016 22:03:39 [SETI@home] Starting task blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.7455.831.17.26.156.vlar_1
27-Apr-2016 22:03:39 [SETI@home] [cpu_sched] Starting task blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.7455.831.17.26.156.vlar_1 using setiathome_v8 version 800 in slot 2
27-Apr-2016 22:03:39 [SETI@home] Task 17mr10aa.19592.25024.13.40.10_1 exited with a DLL initialization error.
27-Apr-2016 22:03:39 [SETI@home] If this happens repeatedly you may need to reboot your computer.
27-Apr-2016 22:03:39 [SETI@home] Computation for task blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.20612.0.17.26.187.vlar_1 finished
27-Apr-2016 22:03:39 [SETI@home] Output file blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.20612.0.17.26.187.vlar_1_0 for task blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.20612.0.17.26.187.vlar_1 absent
27-Apr-2016 22:03:39 [SETI@home] [cpu_sched] Restarting task 17mr10aa.19592.25024.13.40.10_1 using setiathome_v8 version 800 (cuda50) in slot 0
27-Apr-2016 22:03:40 [SETI@home] Starting task blc3_2bit_guppi_57451_27034_HIP69732_0025.5521.416.18.27.155.vlar_0
27-Apr-2016 22:03:40 [SETI@home] [cpu_sched] Starting task blc3_2bit_guppi_57451_27034_HIP69732_0025.5521.416.18.27.155.vlar_0 using setiathome_v8 version 800 in slot 1
27-Apr-2016 22:03:40 [SETI@home] Task 17mr10aa.19592.25024.13.40.10_1 exited with a DLL initialization error.
27-Apr-2016 22:03:40 [SETI@home] If this happens repeatedly you may need to reboot your computer.
27-Apr-2016 22:03:40 [SETI@home] Started upload of 18mr10aa.16813.9883.3.30.98_1_0
27-Apr-2016 22:03:40 [SETI@home] Started upload of blc3_2bit_guppi_57451_26692_HIP69732_OFF_0024.9984.831.17.26.89.vlar_1_0
27-Apr-2016 22:03:40 [SETI@home] Computation for task blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.7455.831.17.26.156.vlar_1 finished
27-Apr-2016 22:03:40 [SETI@home] Output file blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.7455.831.17.26.156.vlar_1_0 for task blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.7455.831.17.26.156.vlar_1 absent
27-Apr-2016 22:03:40 [SETI@home] Computation for task blc3_2bit_guppi_57451_27034_HIP69732_0025.5521.416.18.27.155.vlar_0 finished
27-Apr-2016 22:03:40 [SETI@home] Output file blc3_2bit_guppi_57451_27034_HIP69732_0025.5521.416.18.27.155.vlar_0_0 for task blc3_2bit_guppi_57451_27034_HIP69732_0025.5521.416.18.27.155.vlar_0 absent
27-Apr-2016 22:03:40 [SETI@home] [cpu_sched] Restarting task 17mr10aa.19592.25024.13.40.10_1 using setiathome_v8 version 800 (cuda50) in slot 0
27-Apr-2016 22:03:41 [SETI@home] Starting task blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.24237.831.17.26.172.vlar_0
27-Apr-2016 22:03:41 [SETI@home] [cpu_sched] Starting task blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.24237.831.17.26.172.vlar_0 using setiathome_v8 version 800 in slot 1
27-Apr-2016 22:03:41 [SETI@home] Starting task blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.5492.831.18.27.110.vlar_1
27-Apr-2016 22:03:41 [SETI@home] [cpu_sched] Starting task blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.5492.831.18.27.110.vlar_1 using setiathome_v8 version 800 in slot 2
27-Apr-2016 22:03:41 [SETI@home] Task 17mr10aa.19592.25024.13.40.10_1 exited with a DLL initialization error.
27-Apr-2016 22:03:41 [SETI@home] If this happens repeatedly you may need to reboot your computer.
27-Apr-2016 22:03:42 [SETI@home] [cpu_sched] Restarting task 17mr10aa.19592.25024.13.40.10_1 using setiathome_v8 version 800 (cuda50) in slot 0
27-Apr-2016 22:07:18 [---] Starting BOINC client version 7.6.9 for windows_intelx86
27-Apr-2016 22:07:18 [---] log flags: file_xfer, sched_ops, task, cpu_sched

Note that a couple of the CPU tasks that were initially restarted (18mr10aa.16813.9883.3.30.98_1 and blc3_2bit_guppi_57451_26692_HIP69732_OFF_0024.9984.831.17.26.89.vlar_1) were then reported as finished, resulting in two new tasks starting in their slots. Those both immediately finished with an "Output file .... absent" message. One of those was also replaced with a new task which immediately ended with the same result. All 5 of those tasks ultimately got the -1073741205 error code. Finally, two more CPU tasks were started but at this point BOINC managed to shut down before more damage was done. Those last two tasks were restarted and successfully completed after BOINC was restarted following the system restart.

Oh, and you may notice that task 17mr10aa.19592.25024.13.40.10_1 was restarted 5 times during that 6-second shutdown window, got 4 "DLL initialization error" messages, and yet still completed successfully following the OS and BOINC restart. It was a cuda50 task and raises another question. Why is it only the CPU tasks that ultimately fail while none of the GPU tasks seem to, even though both types seem to get caught in this OS vs. BOINC tug-of-war? Food for thought.
ID: 1791407 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1791422 - Posted: 28 May 2016, 19:02:23 UTC - in response to Message 1791407.  
Last modified: 28 May 2016, 19:09:13 UTC

Quick looks only: General gist is that since by default the applications run at idle priority, their garbage collection can be delayed until other things are complete... So the (normal priority) client will see hung task(s), try kill [Or restart if OS did] them while the system is trying to shut down.

The reason this *appears* new, could superficially be just another manifestation of the ongoing misinterpretation of the Windows threading model that similarly caused finish file present too long etc.

What I mean is:
(older)Linux = Start Threads/Processes --> Kill Worker Processes/threads
Windows = Start Threads-Processes --> Ask for exit, wait patiently
(newer) Linux = Oh now we need to support high bandwidth nVME devices for IO, and the like, we better multithread the block layer devices now .... like Windows

So the simple solution is for the client & apis to move to [check conditions before starting tasks, and] stop killing things, then can't get tripped up trying to kill things while the system is shutting down.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1791422 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1792403 - Posted: 31 May 2016, 2:03:47 UTC

Just managed to generate a large number of these errors on my xw9400.

Since I'd had a little bit of experience (emphasis on "little") with Process Monitor last summer when I was attempting to help out with the troubleshooting of the Stderr truncation problem, I thought perhaps I'd try running Process Monitor during an OS shutdown (without exiting BOINC first) and see if I could capture anything interesting. My first attempt appeared to run as expected, with the same sort of tug-of-war between BOINC and Windows that we've already noted appearing in the Event Log. When the system restarted, it appeared that all 8 of the CPU tasks that were active at shutdown had gotten the -1073741205 error message. Unfortunately, I then discovered that the Process Monitor logging had not been written to disk. It seems the default is for "virtual" logging only, a little tidbit I had forgotten since last summer.

So, of course, I figured I'd just point the logging to a disk file and repeat my previous shutdown/restart process. After the restart, the good news was that I did, indeed have a Process Monitor log file to look at, with 275,858 events (168 MB) to weed through. The bad news was that all but one of the remaining CPU tasks in my queue had been blown away, 71 in all! It appears that while the first BOINC shutdown only required about 7 seconds to complete, the second one took about 47 seconds, providing plenty of time for massive destruction. Sigh...

I'm not sure if the disk logging by Process Monitor was responsible for the slow shutdown, or if it was the fact that BOINC was trying to download a couple of tasks at the time I initiated the shutdown (something that I forget to check on beforehand). Perhaps it was both.

Anyway, now that box is no longer trusted by the scheduler, its "Max tasks per day" is down to 1, and its 8 cores are mostly idle for the time being. It should be interesting to see, however, if the GPU tasks (all of which survived the carnage), especially the Guppi VLARs, run faster for the next few days until the CPU task load gets back up to a normal level.

I don't yet know if there's anything worthwhile in the Process Monitor log, but I'll try picking through it as I have time, and attempt to match it up with what the Event Log shows. Wheeeee.....what fun..........perhaps not. ;^)
ID: 1792403 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1792464 - Posted: 1 Jun 2016, 5:03:26 UTC - in response to Message 1792403.  
Last modified: 1 Jun 2016, 5:06:12 UTC

I don't yet know if there's anything worthwhile in the Process Monitor log, but I'll try picking through it as I have time, and attempt to match it up with what the Event Log shows. Wheeeee.....what fun..........perhaps not. ;^)


Could be worthwhile as illustraion with anoither tool, if practical, just to verify/adapt/refine the sequence:
- machine is crunching
- System shutdown initiated
- OS closes processes (they exit with zero status?)
- Boinc tries to restart them, and generates 'On no you don't', errors

If verifiable, would just mean a workaround of the Boinc client waiting longer before trying to start anything might help, though checking if the system is shutting down first would probably be more robust than such a workaround.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1792464 · Report as offensive
James W

Send message
Joined: 26 May 12
Posts: 51
Credit: 4,956,027
RAC: 13
United States
Message 1792491 - Posted: 1 Jun 2016, 6:18:15 UTC

So would Hibernating Windows cause the same issues with BOINC as actually closing down Windows? Having to close BOINC each time reboot windows or hibernate at end of day one more thing to deal with and a hassle.

Thank you all for your insights.
ID: 1792491 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1792492 - Posted: 1 Jun 2016, 6:19:27 UTC - in response to Message 1792464.  
Last modified: 1 Jun 2016, 6:23:10 UTC

Later: Ugh, just checked the client's main.cpp and, being console, no Windows message handler, so not sure if there is a way to allow it to receive the WM_QUERYENDSESSION, or WM_ENDSESSION messages that would allow it to set a flag.

I think Boinctray.exe has an active message handler though (to be verified), therefore it could set a mutex for the client to say 'don't start tasks, stuff is shutting down'
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1792492 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1792493 - Posted: 1 Jun 2016, 6:21:51 UTC - in response to Message 1792491.  

So would Hibernating Windows cause the same issues with BOINC as actually closing down Windows? Having to close BOINC each time reboot windows or hibernate at end of day one more thing to deal with and a hassle.

Thank you all for your insights.


Not sure on hibernate. Most likely if they check the system isn't shutting down before (re)starting tasks, then possible weirdness there would go away too.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1792493 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1792495 - Posted: 1 Jun 2016, 6:34:24 UTC - in response to Message 1792492.  
Last modified: 1 Jun 2016, 6:37:37 UTC

Later: Ugh, just checked the client's main.cpp and, being console, no Windows message handler, so not sure if there is a way to allow it to receive the WM_QUERYENDSESSION, or WM_ENDSESSION messages that would allow it to set a flag.

I think Boinctray.exe has an active message handler though (to be verified), therefore it could set a mutex for the client to say 'don't start tasks, stuff is shutting down'


Something like this (untested) addition in boinctray.exe would let its active message handler receive shutdown notifications, and set a global mutex for Boinc to check before starting any tasks:

// Handle window messages for main screensaver windows.
//
LRESULT CBOINCTray::TrayProc(
HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam
) {
switch (uMsg) {
case WM_QUERYENDSESSION:
case WM_ENDSESSION:
CreateMutex( ..., ..., "BoincTraySystemShutdownMutex");
break;


case WM_CREATE:
CreateDataManagementThread();
return 0;
break;

case WM_CLOSE:
DestroyDataManagementThread();
return 0;
break;
}
return DefWindowProc(hWnd, uMsg, wParam, lParam);
}

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1792495 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14645
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1792591 - Posted: 1 Jun 2016, 15:05:27 UTC - in response to Message 1792403.  
Last modified: 1 Jun 2016, 15:14:43 UTC

Just managed to generate a large number of these errors on my xw9400.

Interesting that your errors are showing as:

Exit status	3221226091 (0xc000026b) Unknown error number

That's much more searchable than (0xffffffffc000026b): I wonder if it's because you're using a 32-bit operating system?

The PHP display code (from result.inc) is

function exit_status_string($x) {
    return sprintf("%d (0x%x)", $x, $x). " ".result_error_mask_str($x);
}

I wonder if a different format specifier than %x could force it to 32 bits? Ideas, anyone?

Edit - nobody seems to have covered that in http://php.net/manual/en/function.sprintf.php
ID: 1792591 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1792600 - Posted: 1 Jun 2016, 16:07:22 UTC - in response to Message 1792591.  

Verrrry interesting. Somebody's been doing some tinkering behind the scenes. Here's the Task Detail for 4960248868 exactly as I captured it on Monday evening:
Name	17jl10ab.2255.131566.10.37.5_0
Workunit	2173204346
Created	30 May 2016, 17:06:25 UTC
Sent	30 May 2016, 23:43:33 UTC
Report deadline	23 Jul 2016, 4:49:58 UTC
Received	30 May 2016, 23:52:30 UTC
Server state	Over
Outcome	Computation error
Client state	Compute error
Exit status	-1073741205 (0xffffffffc000026b) Unknown error number
Computer ID	6980751
Run time	
CPU time	
Validate state	Invalid
Credit	0.00
Device peak FLOPS	0.00 GFLOPS
Application version	SETI@home v8
Anonymous platform (CPU)
Stderr output

<core_client_version>7.6.22</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code -1073741205 (0xc000026b)
</message>
]]>

...and here's what it looks like now on the site:
Name	17jl10ab.2255.131566.10.37.5_0
Workunit	2173204346
Created	30 May 2016, 17:06:25 UTC
Sent	30 May 2016, 23:43:33 UTC
Report deadline	23 Jul 2016, 4:49:58 UTC
Received	30 May 2016, 23:52:30 UTC
Server state	Over
Outcome	Computation error
Client state	Compute error
Exit status	3221226091 (0xc000026b) Unknown error number
Computer ID	6980751
Run time	
CPU time	
Validate state	Invalid
Credit	0.00
Device peak FLOPS	0.00 GFLOPS
Application version	SETI@home v8
Anonymous platform (CPU)
Stderr output

<core_client_version>7.6.22</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code -1073741205 (0xc000026b)
</message>
]]>

Even though the Stderr itself hasn't changed, the Exit Status in the header has morphed from "-1073741205 (0xffffffffc000026b)" to "3221226091 (0xc000026b)".
ID: 1792600 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14645
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1792603 - Posted: 1 Jun 2016, 16:21:34 UTC - in response to Message 1792600.  

Great stuff. I did email a request for that change to be made, but I didn't receive any acknowledgement, and I haven't seen any checkin to the master source code that seemed to match (since 28 May, which is when I emailed).

Maybe they're testing it here before releasing it to the wider community. I hope that wasn't what crashed Oscar!
ID: 1792603 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1792607 - Posted: 1 Jun 2016, 16:34:04 UTC - in response to Message 1792603.  

Great stuff. I did email a request for that change to be made, but I didn't receive any acknowledgement, and I haven't seen any checkin to the master source code that seemed to match (since 28 May, which is when I emailed).

Maybe they're testing it here before releasing it to the wider community. I hope that wasn't what crashed Oscar!

I suppose if the exit status is actually stored in text format in the BOINC DB, then they would have had to run some sort of utility to modify each and every task record in the DB. It would make more sense, though, if the exit code was just converted for display purposes when a task page is requested. But then, "make more sense" isn't always the standard mode of operation around here, is it? ;^)
ID: 1792607 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14645
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1792611 - Posted: 1 Jun 2016, 16:50:46 UTC - in response to Message 1792607.  

Extract from the database schema:

create table result (
    ....
    exit_status             integer         not null,

Looks like it was done right, and that PHP function was correct for turning an integer into a formatted string ready for display.

I very much doubt that they changed the data stored in the table: more likely there's an uncommitted change in the display code or the glue code linking the web site to the database.
ID: 1792611 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1792630 - Posted: 1 Jun 2016, 17:55:43 UTC - in response to Message 1792611.  

Good. Not likely the cause of Oscar's downfall then. :^)
ID: 1792630 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1792760 - Posted: 2 Jun 2016, 3:13:24 UTC

Just noticed that the wingman on one of my error tasks from Monday evening, host 7440776, also got the same error. In fact, he currently appears to have generated at least 170 of them over the last 4 days. That host is also Windows 7 running BOINC 7.6.9. One major difference I see, however, is that he's also getting the error on Cuda tasks, something I haven't experienced (yet).

I'm getting the sense that if we really looked for them, we'd find that this is becoming an increasingly common error and something worth keeping an eye on to see if it's possible to nail down the configurations where it occurs.
ID: 1792760 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1792772 - Posted: 2 Jun 2016, 4:15:14 UTC - in response to Message 1792760.  
Last modified: 2 Jun 2016, 4:15:59 UTC

Have seen some activity on the Boinc dev mailing list, and looks like some form of shutdown detection, currently missing on Windows clients, may be added (WM_QUERYENDSESSION handler, or some console handler equivalent where that message isn't available). Probably will take them a bit to get to alpha state.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1792772 · Report as offensive
1 · 2 · 3 · 4 . . . 6 · Next

Message boards : Number crunching : 1073741205 Error Code (Unknown Error)


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.