The replica database will be offline until we can restore it from the primary database on tuesday (at the earlies). This will result in slowness of the web site and the scheduler.

I have an update request on one of my machines that is about 300 megs and for the heck of it I told it to go ahead.

I let it set there for about 15 minutes and it never did download anything. Figuring that I had done something wrong, I rebooted and tried it again, still nothing. I guess they don't really want to update my machine and are just teasing me....ha!

This was a phenomenon I noticed a while back when getting updates from MS directly and when getting updates from my local WSUS server.

When checking for--and downloading--updates from MS, there seems to be a ton of disk activity and CPU usage, as the Update client is scanning all the files on your computer that would be affected by the update, to see if you need portions of it or not. You end up downloading only part of the update because you don't need all of it.

When checking for--and downloading--updates from WSUS, there is minimal disk activity and CPU usage, and the download starts almost right away and begins installing, because it doesn't check the individual files that would be affected, it's just a simple check of "X update is available on the server and is not currently installed on the client machine. Begin downloading update to install on client machine."



Especially with larger updates, when downloading directly from MS, you'll have to let it sit for a while.

I let it set there for about 15 minutes and it never did download anything. Figuring that I had done something wrong, I rebooted and tried it again, still nothing. I guess they don't really want to update my machine and are just teasing me....ha!

I think there's something broken in the update client right now. Had a Win7 box the other night that sat forever showing 0% complete on updates, couldn't seem to get them to download, but when I went to look at detail, they were all there waiting for install ... did a shutdown and everything loaded, eventually ...

Unless there's a danger of a missed deadline, it runs them in the order they were received from the server. First In, First Out. Simple as that.

If that is the case, and I'm sure it is since you are the one saying so, why does it sometimes stop an in progress WU and run another one that it has just received?

The size of your cache, how often your system is set to check for work, the time it takes to process work, any other projects you might have & their settings, the time your system is able to process work all go in to determining if there is the chance of a missed deadline.

Unless there's a danger of a missed deadline, it runs them in the order they were received from the server. First In, First Out. Simple as that.

And I'm presuming that it will take an act of God for a non-volume licensed, or should I say a non-enterprise licensed individual to acquire such a version, if it's even possible at all? Doesn't leave us end users with many good options after 2020 then, sadly, when are going to get XP'ed. Unless we suck it up and move to 8, to buy a couple more years. I guess the saying is accurate, Resistance is Futile, you will be Assimilated...

Perhaps sometime in the future I will come across some more clues and finally solve this unusual problem.

Process Monitor might be the best option.

Fire it up, run the BOINC installer, then check to see what was happening just prior to the BEX64 error.

You could check stderrdae.txt in BOINC's data directory if the client had a chance to log the error there.

Did you try 7.6.33?

One possible solution is to add a start up delay to your cc_config.xml file:

<start_delay>nseconds</start_delay>


I had to do this on one of my crunchers some time ago for much the same reason as you are suffering just now - I think I used a 120 second delay.
The delay gives the drivers time to get going properly before BOINC starts to do its system probing to see what hardware is available.

edit:
Under Windoze 7 the default location of cc_config is c:\ProgramData\BOINC (by default this folder is hidden)

One possible solution is to add a start up delay to your cc_config.xml file:

<start_delay>nseconds</start_delay>


I had to do this on one of my crunchers some time ago for much the same reason as you are suffering just now - I think I used a 120 second delay.
The delay gives the drivers time to get going properly before BOINC starts to do its system probing to see what hardware is available.

edit:
Under Windoze 7 the default location of cc_config is c:\ProgramData\BOINC (by default this folder is hidden)

The most useful link I've been able to find concerning "Problem Event Name:BEX64" issues.
What does event BEX64 mean?

There are some references that BEX stands for "Buffer Overflow Exception" and is somehow related to Data Execution Prevention.
...

Indicates a buffer overflow (/GS) or DEP exception (BEX64 indicates a buffer overflow (/GS) or DEP exception on 64-bit versions of Windows)
I translate that to a couple of programmes interfering with each other, and in this case the BOINC installer comes off second best.


Found another site, and there the issue relates to a programme having issues with extremely long file names on some folders. Remove the folder with the extremely long file name & no more BEX64 errors.

Very odd and interesting. Should I go hunting.....grin Perhaps I should!


Fixing BEX64 error nvcplui.exe

BEX64 NVcplui.exe and nvgames.dll error in manage 3d settings
In process monitor, it showed that the nvcplui.exe was for some reason interacting with these long named folders/directories. Many programs are not designed to recognize or handle long names like the above example and usually will crash. Sure enough that was the problem. I moved all my folders and personal stuff off the desktop and to a different partition (in this case D drive). I then relaunched the application and the manage 3d settings worked perfectly. To test if this was the problem, I put back the items I had moved off the desktop and launched the application again and sure enough it crashed at the manage3d settings.