Brings to mind if it will become cheaper for business to provide workers with VR/AR workspaces, than maintain large amounts of office space. Could probably cram in a lot more cubicules...

---

"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.

Brings to mind if it will become cheaper for business to provide workers with VR/AR workspaces, than maintain large amounts of office space. Could probably cram in a lot more cubicules...

nah, you'll be expected to build your own cubicle at home.

Brings to mind if it will become cheaper for business to provide workers with VR/AR workspaces, than maintain large amounts of office space. Could probably cram in a lot more cubicules...

nah, you'll be expected to build your own cubicle at home.

Oh, Open Source :p

---

"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.

Naaa, I think it'll be more along the lines of the Matrix, where we're just plugged into massive banks of Pods, or maybe each person will have their own pod they are required to jack into every day...

Or, maybe all day...








Forever!! BWhahahaha!

---

OK, playtime over - back to the bughunt.

I've built a BOINC client - well, two of them, 32 bit and 64 bit - from the 'Head' code, thus incorporating Rom's attempt at a fix for the 'kill cache while closing down Windows' problem.

These should run as a direct replacement for client v7.6.22, except - because I've build using VS2013 - you may need to update your Visual C++ Redistributable Packages for Visual Studio 2013.

Get the clients from here - both bitnesses in subfolders in the same zip.

My private builds all disable the "pseudo-progress" estimation code for debugging the progress reported by applications, but are otherwise pure BOINC code. Which may lead to some surprises:

02/06/2016 14:00:54 |  | <![CDATA[Starting BOINC client version 7.7.0 for windows_x86_64]]>

but apart from that, it's been running without error while I compose this.

Now to see if we can break it...

Well, I've tried to reproduce the problem on another machine with the standard v7.6.22 client, but that was too polite to kill anything.

02-Jun-2016 15:15:13 [Einstein@Home] Task PM0137_033B1_238_1 exited with zero status but no 'finished' file
02-Jun-2016 15:15:13 [Einstein@Home] If this happens repeatedly you may need to reset the project.
02-Jun-2016 15:15:13 [SETI@home] Task 20se10ab.508.18472.9.36.15_0 exited with zero status but no 'finished' file
02-Jun-2016 15:15:13 [SETI@home] If this happens repeatedly you may need to reset the project.
02-Jun-2016 15:15:13 [SETI@home] Task blc5_2bit_guppi_57451_26010_HIP69732_OFF_0022.1995.831.18.27.132.vlar_0 exited with zero status but no 'finished' file
02-Jun-2016 15:15:13 [SETI@home] If this happens repeatedly you may need to reset the project.
02-Jun-2016 15:15:13 [SETI@home] Task 20se10ab.20838.67.8.35.25_1 exited with zero status but no 'finished' file
02-Jun-2016 15:15:13 [SETI@home] If this happens repeatedly you may need to reset the project.
02-Jun-2016 15:15:13 [SETI@home] Task 20au10ab.8139.4161.13.40.146_1 exited with zero status but no 'finished' file
02-Jun-2016 15:15:13 [SETI@home] If this happens repeatedly you may need to reset the project.
02-Jun-2016 15:15:13 [Einstein@Home] [cpu_sched] Restarting task PM0137_033B1_238_1 using einsteinbinary_BRP6 version 152 (BRP6-Beta-opencl-intel_gpu) in slot 6
02-Jun-2016 15:15:13 [SETI@home] [cpu_sched] Restarting task 20se10ab.508.18472.9.36.15_0 using setiathome_v8 version 800 (cuda50) in slot 4
02-Jun-2016 15:15:13 [SETI@home] [cpu_sched] Restarting task blc5_2bit_guppi_57451_26010_HIP69732_OFF_0022.1995.831.18.27.132.vlar_0 using setiathome_v8 version 800 (cuda50) in slot 5
02-Jun-2016 15:15:13 [SETI@home] [cpu_sched] Restarting task 20se10ab.20838.67.8.35.25_1 using setiathome_v8 version 800 (cuda50) in slot 3
02-Jun-2016 15:15:13 [SETI@home] [cpu_sched] Restarting task 20au10ab.8139.4161.13.40.146_1 using setiathome_v8 version 800 (cuda50) in slot 7
02-Jun-2016 15:15:41 [---] Starting BOINC client version 7.6.22 for windows_x86_64

- but that was possibly because this is a new machine, with an SSD and very little clutter. You can see that BOINC was back up and crunching in less than 30 seconds. Maybe I need to try again next Patch Tuesday - closing a dozen browser tabs, three BOINC Managers, and a copy of BoincView simply didn't take long enough to restart anything to the danger point.

I like the tags https://github.com/BOINC/boinc/issues/1553 was awarded :)

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

In looking back over my Event Logs, most of the time that's the sort of scenario that I've seen. The whole "restart during shutdown" sequence of messages appear for one or more tasks, but the delay is ultimately insufficient to actually cause the tasks to error out. In fact, from last December (the earliest I can track the problem) until late April, that's all that ever happened. For some reason, about that time both of my Win 7 machines started to get the errors. It seems plausible (though just a guess) that one of the Windows updates has caused the shutdown process to run more slowly.

If you're looking for a way to stretch out the shutdown, you might try cranking up Process Monitor just before shutdown. That certainly seemed like it was the determining factor in flushing nearly my entire queue of CPU tasks on Monday evening!

What I don't quite understand is why we are suddenly seeing these errors.

Those who experienced them, can you pinpoint when it started? And while we are there, can you check if we are looking at a problem when a task first starts, when it restarts or even something that happens to running tasks.

Doing a controlled shutdown experiment and examining the entrails might help.

What kind of shutdown was it anyway?

I can't pinpoint when it started, but I have Event Logs going back to last December showing the "restart during shutdown" scenario. However, no actual error tasks resulted until late April.

It seems to strictly be a condition that occurs when Windows is shut down while BOINC is still running. The shutdown can either be manual or automated. (My crunch-only machines are automatically shut down at a specified time on weekday afternoons.) It appears to me that the OS starts shutting down the individual task processes before BOINC knows the shutdown is occurring (or at least before BOINC acts on it) so BOINC thinks the tasks just died on their own and tries to restart them. Why that DLL initialization error begins to appear after the initial restarts is not clear.

As far as a controlled shutdown experiment goes, that's what I tried doing on Monday evening, as noted in an earlier message. I have a Process Monitor log (168 MB worth) and stdoutdae log that I hope might provide some info, but sifting through it takes a lot of time when one really doesn't know what he's doing. (I used to be pretty good at this sort of thing way back when dinosaurs ruled the [computer] world, but I'm kind of starting from scratch here.) If anybody better-equipped than me would like to see those logs, I could probably upload them to a cloud somewhere.

Does the Windows version log any messages that it's exiting like this one?

02-Jun-2016 20:06:13 [---] Exiting

There's a program called SendMessage over here. It can be used to send arbitrary window messages to any window. It would be good to test that the client responds to Window's shutdown message by using SendMessage to send WM_QUERYENDSESSION to the client's window.

The last time I run Windows version I started it from command prompt without command line options. In that mode the client outputs log messages to the command prompt window and responds to Control-C by exiting. Wouldn't hurt to test the Control-C handler too.

Does the Windows version log any messages that it's exiting like this one?

02-Jun-2016 20:06:13 [---] Exiting

There's a program called SendMessage over here. It can be used to send arbitrary window messages to any window. It would be good to test that the client responds to Window's shutdown message by using SendMessage to send WM_QUERYENDSESSION to the client's window.

The last time I run Windows version I started it from command prompt without command line options. In that mode the client outputs log messages to the command prompt window and responds to Control-C by exiting. Wouldn't hurt to test the Control-C handler too.

My question is, would you like it broken in just that way ?

---

"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.

Does the Windows version log any messages that it's exiting like this one?

02-Jun-2016 20:06:13 [---] Exiting

It's inconsistent. On my daily driver, that line only appears perhaps 10% of the time. On my other Win 7 machine, it appears more frequently, but varies from day to day, such as:

25-May-2016 15:59:00 [SETI@home] [cpu_sched] Preempting 28se10aa.22222.20926.3.30.65_1 (removed from memory)
25-May-2016 15:59:00 [SETI@home] [cpu_sched] Preempting 28se10aa.22222.22153.3.30.36_0 (removed from memory)
25-May-2016 21:33:12 [---] Starting BOINC client version 7.6.22 for windows_intelx86
25-May-2016 21:33:12 [---] log flags: file_xfer, sched_ops, task, cpu_sched

vs.

26-May-2016 15:59:00 [SETI@home] [cpu_sched] Preempting 28se10aa.29476.15609.11.38.45_1 (removed from memory)
26-May-2016 15:59:00 [SETI@home] [cpu_sched] Preempting 28se10aa.29476.16836.11.38.126_1 (removed from memory)
26-May-2016 15:59:43 [---] Exiting
26-May-2016 21:02:23 [---] Starting BOINC client version 7.6.22 for windows_intelx86
26-May-2016 21:02:23 [---] log flags: file_xfer, sched_ops, task, cpu_sched
2

I'm not sure that it ever appears when the "restart after shutdown" scenario is occurring.

Does the Windows version log any messages that it's exiting like this one?

02-Jun-2016 20:06:13 [---] Exiting

There's a program called SendMessage over here. It can be used to send arbitrary window messages to any window. It would be good to test that the client responds to Window's shutdown message by using SendMessage to send WM_QUERYENDSESSION to the client's window.

The last time I run Windows version I started it from command prompt without command line options. In that mode the client outputs log messages to the command prompt window and responds to Control-C by exiting. Wouldn't hurt to test the Control-C handler too.

Yes.

07-May-2016 09:53:18 [SETI@home] work fetch suspended by user
07-May-2016 09:53:46 [---] Exiting
07-May-2016 09:53:53 [---] Starting BOINC client version 7.6.22 for windows_x86_64

That looks like planned maintenance of some sort on my part, but I've forgotten what.

But.....

I think Windows programs tend to have two different modes of shutdown - interactive and silent. 'Interactive' for when you're there and able to respond to dialogs like "Save untitled.txt?": silent for when Windows is forcing a closedown.

And I think BOINC - the Manager, certainly - implements both versions. We had problems a few years ago when configuration changes were held in memory, volatile, and only flushed to disk during an interactive shutdown (say from the file|Exit menu), and not saved if BOINC was shutting down in response to a 'Windows is closing' message. That was solved by saving config changes to disk immediately, but I think the separate exit paths probably both still exist. We'd need to look (separately) at both Client and Manager code to be certain.

My question is, would you like it broken in just that way ?

Sorry, I don't understand.

I'm not sure that it ever appears when the "restart after shutdown" scenario is occurring.

That strongly suggests that the Client, too, has both 'interactive' and 'silent' shutdown modes - though without a UI, it's not quite clear why. 'Exiting' would be a response to an interactive shutdown initiated by a Manager.

My question is, would you like it broken in just that way ?

Sorry, I don't understand.

Just I see no Window handler (for receiving WM_QUERYENDSESSION), or window, in the boinc client. (except service mode perhaps)
(maybe you could point it out)

---

"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.

Just I see no Window handler (for receiving WM_QUERYENDSESSION), or window, in the boinc client. (except service mode perhaps)
(maybe you could point it out)

There's both WM_QUERYENDSESSION and CTRL_*_EVENT handlers in sysmon_win.cpp.

edit: Maybe I should add some remark about grep. :)

Just I see no Window handler (for receiving WM_QUERYENDSESSION), or window, in the boinc client. (except service mode perhaps)
(maybe you could point it out)

There's both WM_QUERYENDSESSION and CTRL_*_EVENT handlers in sysmon_win.cpp.

edit: Maybe I should add some remark about grep. :)

Now explain why they start tasks if they receive WM_QUERYENDSESSION , answer is they don't receive them, because console program :)

---

"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.

I'm not sure that it ever appears when the "restart after shutdown" scenario is occurring.

That strongly suggests that the Client, too, has both 'interactive' and 'silent' shutdown modes - though without a UI, it's not quite clear why. 'Exiting' would be a response to an interactive shutdown initiated by a Manager.

I think it's either the client doesn't always receive the shutdown message or that the client takes too long to shutdown the apps and gets killed before the log line is flushed to the disk.

There's both WM_QUERYENDSESSION and CTRL_*_EVENT handlers in sysmon_win.cpp.

With comments like

// If we are not installed as a service, begin the task shutdown process
// when we are notified that the system is going down. If we are installed
// as a service, wait until the service control manager tells us to shutdown.
//
// The console handler happens a little to late in the cycle and leads
// to BOINC attempting to start new tasks, which fail, when the OS has
// shutdown some of the ones that were executing.

https://github.com/BOINC/boinc/blob/master/client/sysmon_win.cpp#L157

That's the sort of thinking which should have kept us out of this mess in the first place.