Does GridRepublic not have it's own custom BOINC Agent, which then begs the question if they include [have included all the security features needed for WCG]. So happens some weeks ago to have seen some work done on the GR specific 6.8 client, which was this release of August 22, 2012: http://boinc.berkeley.edu/dl/gridrepublic_6.8.44_windows_intelx86.exe and this of Aug.14 http://boinc.berkeley.edu/dl/boinc_081412_macOSX_i686.zip There were several more 6.8.44 builds, but you'd really have to check over at GR why or what this was for. WCG requires certificate checking and port 443 open. Any message log from the WCG attach fail would give us a pointer why this fails. Are you doing this from within GR or directly in the client?

That said, I've had GR on a regular BOINC/WCG build without issue. I got off their program some years ago because they were not respecting a certain setting I had and went about to delete my account there.

If I was easily scared, it would be with that word "Latest"... could be a first alpha test build that mangles everything. What exact version is this "Latest"?

Is the GR Account manager attached to the client? If so, temp detach from GR. Then, suspend all projects in the Projects tab except WCG. After, hit update, after selecting WCG in the projects tab. See what happens... it work is fetched it may be just the resource share.

If still no work comes, replace content of the cc_config.xml file with this, which creates a bunch of extra logging messages in the client. After, use the advanced menu "Read config" to effectuate [this is recorded in message log if successful] and hit update again in the client, then post if still no work has come.

<cc_config>
<log_flags>
<file_xfer>1</file_xfer>
<sched_ops>1</sched_ops>
<task>1</task>
<app_msg_receive>0</app_msg_receive>
<app_msg_send>0</app_msg_send>
<async_file_debug>0</async_file_debug>
<benchmark_debug>0</benchmark_debug>
<checkpoint_debug>1</checkpoint_debug>
<coproc_debug>0</coproc_debug>
<cpu_sched>1</cpu_sched>
<cpu_sched_debug>0</cpu_sched_debug>
<cpu_sched_status>0</cpu_sched_status>
<dcf_debug>1</dcf_debug>
<disk_usage_debug>0</disk_usage_debug>
<priority_debug>0</priority_debug>
<file_xfer_debug>1</file_xfer_debug>
<gui_rpc_debug>0</gui_rpc_debug>
<heartbeat_debug>0</heartbeat_debug>
<http_debug>1</http_debug>
<http_xfer_debug>1</http_xfer_debug>
<mem_usage_debug>0</mem_usage_debug>
<network_status_debug>1</network_status_debug>
<poll_debug>0</poll_debug>
<proxy_debug>1</proxy_debug>
<rr_simulation>0</rr_simulation>
<rrsim_detail>0</rrsim_detail>
<sched_op_debug>1</sched_op_debug>
<scrsave_debug>0</scrsave_debug>
<slot_debug>0</slot_debug>
<state_debug>0</state_debug>
<statefile_debug>0</statefile_debug>
<suspend_debug>0</suspend_debug>
<task_debug>0</task_debug>
<time_debug>1</time_debug>
<trickle_debug>0</trickle_debug>
<unparsed_xml>0</unparsed_xml>
<work_fetch_debug>1</work_fetch_debug>
<notice_debug>0</notice_debug>
</log_flags>
<options>
</options>
</cc_config>

Sorry about the late reply, I've been too busy to think!

I actually tried about six more times, and eventually got it to work! I didn't change a thing, so I'm not sure what the actual problem was, but it's working fine now. I'm saving a link to this thread in case it happens again, and I can try your tip.

Thanks for the help!