MJH:

Regarding the "display driver constantly crashing" issue, it's important that you look into the problem here:
http://www.gpugrid.net/forum_thread.php?id=3491
... in order to ensure that other users do not suffer the same fate.

My workaround for it was to log into Windows, and while the display driver was crashing repeatedly, desperately try to get to the BOINC menu to select "Disable GPU". Once that was disabled, I aborted the offending/stuck GPUGrid.net tasks.

Note: This has nothing to do with the "Access violation" errors (which are a completely different issue, and which will show up in the stderr.txt log when the work units are uploaded). As such, I will try not to post again within this thread, about the "display driver constantly crashing" issue.

Thanks for listening,
Jacob

Robert, you might want to try the following,
Go to the location of the Boinc Manager (default is C:\Program Files\BOINC), alternate click on the application, select Properties, click the Compatibility Tab and set the Privilege Level to Run the program as an administrator. Then click 'Change setings fro all users' and set the privilege level to Run as administrator. Click OK, Apply, OK and restart the system.

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

MJH:

Regarding the "display driver constantly crashing" issue, it's important that you look into the problem here:
http://www.gpugrid.net/forum_thread.php?id=3491
... in order to ensure that other users do not suffer the same fate.

My workaround for it was to log into Windows, and while the display driver was crashing repeatedly, desperately try to get to the BOINC menu to select "Disable GPU". Once that was disabled, I aborted the offending/stuck GPUGrid.net tasks.

Note: This has nothing to do with the "Access violation" errors (which are a completely different issue, and which will show up in the stderr.txt log when the work units are uploaded). As such, I will try not to post again within this thread, about the "display driver constantly crashing" issue.

Thanks for listening,
Jacob

Many people have had this issue and had to figure out how to catch BOINC before the crashes start again.

I have BOINC set to not start automatically because of all the TDRs I've had recently.

So I get the system back up and running after the TDR, click the BOINC shortcut and poise my mouse pointer over the GPUGrid project line so I can hit the 'Suspend' button before it all crashes again. I've gotten pretty good at it.

That way I can switch to the tasks panel and abort whatever was running because they will all be corrupted and completely worthless as a result of the TDR that happened (on whichever GPU crashed at the time).

I think Richard Haselgrove had a more elegant way of preventing blue screen crashes after recovery/reboot by editing some xml file to fool BOINC into thinking the project was suspended before attempting to start BOINC up, but I don't remember the details.

Operator

---

Another option is, within the cc_config.xml file, within the <options> block, you can set a <start_delay>.
Details here: http://boinc.berkeley.edu/wiki/Client_configuration

So, for instance, you could do the following to have BOINC delay running until 30 seconds after it normally would:

<cc_config>
	<options>
		<start_delay>30</start_delay>
	</options>
</cc_config>

I think Richard Haselgrove had a more elegant way of preventing blue screen crashes after recovery/reboot by editing some xml file to fool BOINC into thinking the project was suspended before attempting to start BOINC up, but I don't remember the details.

Operator

Quoting from message 33277:

My workround has been to restart Windows in safe mode (which prevents BOINC loading), and edit client_state.xml to add the line

    <suspended_via_gui/>

to the <result> block for the suspect task.

As the name suggests, that's the same as clicking 'suspend' for the task while BOINC is running, and gets control of the machine back so you can investigate on the next normal restart. By convention, the line goes just under <plan_class> in client_state, but I think anywhere at the first indent level will do.

Robert, you might want to try the following,
Go to the location of the Boinc Manager (default is C:\Program Files\BOINC), alternate click on the application, select Properties, click the Compatibility Tab and set the Privilege Level to Run the program as an administrator. Then click 'Change setings fro all users' and set the privilege level to Run as administrator. Click OK, Apply, OK and restart the system.

Doesn't seem necessary now - BOINC is now running properly under the administrator account.

A workunit you may want to assign an Error result to:

http://www.gpugrid.net/result.php?resultid=7348712

That's the one that was in progress when the crashes started, and was lost from that computer' BOINC database during the recovery. In other words, now a phantom workunit.

It may or may not be significant that after the recovery, the BOINC version in use was 7.0.56. Now upgraded to 7.0.64, though.

The phantom WU will clear from your list in around 2weeks.

Sounds like your system recovered to a time when a previous version of BOINC was installed. I expect your system associated the crash with Boinc and went to a previous version.

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

I ran a couple of WUs over the weekend on my GTX 460 after updating to driver 331.40 and had no problems.

However, I did not notice this problem to begin with.

http://www.gpugrid.net/workunit.php?wuid=4840060
http://www.gpugrid.net/workunit.php?wuid=4838699

---

Strangely enough I did a project reset and my access violations went away. Didn't do anything else. Go figure.

With driver 326.80 my 660 ran for 10 days continuously without any error or fatal cuda driver and thus a downclock of the GPU clock.

Then 6 days ago I needed to reboot the system for a Windows update and thought I can afterwards install latest driver 331.40.
I did a clean install and reboot again. Now it has already three times a fatal cuda driver error and a downclock, which only can be resolved by booting.

Have more people seen this fatal cuda driver (in stderr) with this beta driver on another card then 780 or Titan?

---

Greetings from TJ

With driver 326.80 my 660 ran for 10 days continuously without any error or fatal cuda driver and thus a downclock of the GPU clock.

Then 6 days ago I needed to reboot the system for a Windows update and thought I can afterwards install latest driver 331.40.
I did a clean install and reboot again. Now it has already three times a fatal cuda driver error and a downclock, which only can be resolved by booting.

Have more people seen this fatal cuda driver (in stderr) with this beta driver on another card then 780 or Titan?

The discussion thread with some examples is in Number crunching.