Oh well. Hopefully avoiding using curl as much as possible with raw sockets on stratum in 2.10.1 fixes it.

This is not the right place. Check the stratum thread. And the proxy is in python so needs no compiling, just python.

Increase the fee on getwork pools. End of story.

New version: 2.10.1, 14th December 2012

Mainly to try and fix the windows+stratum disconnect bug.


Human readable changelog:

Converted the curl code that was where all the crashing on windows was occurring into the raw code equivalents. Hopefully this quashes the crashes with stratum on various flavours of windows.
Ztex and MMQ updates.
Miner.php updates
New API features and code improvements.


Full changelog:

- Check for EWOULDBLOCK when supported in send and recv as well.
- Use the raw send() command instead of curl_easy_send since curl raw socket
usage introduces random bugs on windows.
- Use raw recv() command in place of curl_easy_recv since the curl
implementation introduces random bugs on windows builds when the recv fails.
- miner.php when displaying a single rig, add prev/next rig buttons if they
exist, next to refresh
- miner.php allow custom page joins for STATS
- API show if pool has GBT (so people know not to use that pool)
- miner.php - include windows easyphp link
- driver-ztex: use the correct size for the swap array
- API stats - display pool byte transfer stats
- Pool store data transfer stats
- README ModMiner dependency
- Benchmark incorrect work size
- ChangeLog refer to NEWS
- MMQ handle over temp differently and hash longer
- driver-ztex: search the complete noncerange based on the actual speed
- README - update ModMiner details
- API-README update
- api use a dynamic io buffer, truncated before it reaches the current ~64k
limit

Despite the windows+stratum bugs that people are still encountering with 2.10.0, they are no worse than with 2.9.7, and no real showstopper bugs have shown up on 2.10.0 apart from lots of leaking shares when the primary pool is getwork without rolltime (which pools are still that bad!?). So despite the fact that windows+stratum disconnect is still problematic, I am going to raise the status of 2.10.0 to stable since it is no worse than the 2.9 branch. The substantial changes in 2.10 were all actually in the scheduling of work and there has not been a significant bug there as far as I can tell.

I will continue to pursue these windows bugs till no one is mining on windows any more... uh I mean till hopefully I can find wtf is uniquely wrong on windows. I'm so annoyed that 99% of my debugging effort is now directed to windows specific issues that I find myself wishing that I had made cgminer linux only. I could probably develop cgminer much faster if it was possible to drop windows support. Of course that's crazy talk...</rant>

EDIT: Note I will likely be releasing 2.10.1 shortly anyway.

Coincidence related to something else maybe like a driver change. The GPU code hasn't been touched in any significant way in many months.

The only openCL implementation for nvidia devices is through the cuda driver, meaning it goes cgminer->opencl->cuda->GPU. There is no way to do native cgminer->cuda->GPU. It's not at all worth it since the performance is identical, and they earn no money and GPU mining is on the way out. Throw me 1000 BTC and I'll make you a native cuda version, but it's not going to be of any advantage.

That's correct.

Which is good because that's what it's supposed to be. Performance with current hardware (i.e. no asics) should have maximised with stratum support already. The changes in 2.10 are for the future.

You only get a windows+stratum crash after 2.8.7?

There's an interesting thought, and it's not the first time this has been encountered - it could well be the optimised build that leads to crashes only.

Sure. Unfortunately 9 times out of 10 I don't get useful information from windows crashes even with the debug version 

From the command line:
--compact           Use compact display without per device statistics

Or from the menu while it's running, press D for display and you'll see it there.
It does get rid of all the device stats tho.

compact mode, or use more remote monitoring with something like miner.php

I've uploaded some fresh debug builds for windows here for those who want to try and help me get debug information:

http://ck.kolivas.org/apps/cgminer/debug/

These builds have optimisations disabled to hopefully try and get meaningful debug information out of them. It's annoying how hard windows builds are to debug...

Oh and the libcurl dll included in the 2.10.0 archive is already one with the fix from 2.9.7 (even though it's a different size) so there's no point trying a different dll if you are getting crashes.

DrHaribo means cgminer doesn't change the time stamp with stratum, which it doesn't since I didn't see the point. Since most pools update stratum structures with a push every 30 seconds, the time can be out by 30 seconds. Compare with ntime rolling where it can be out by 2 hours... I didn't see much point in trying hard to get the time correct to within 1 second.

Thanks for that but for such a convoluted process for the sake of one clock call when GPUs will be redundant in a couple of months seems a waste now - i.e. I'm not interested in developing in any significant fashion for GPUs any more. On the other hand, as you see from Kano's message, there are certainly other clock functions he implemented that suffer under windows that will be relevant to him.

You still haven't understood? To go through all the nonces with stratum currently as is, would require it to check 18,446,744,073,709,551,616 hashes. If that's not enough, you can just increase the size of nonce2 from 4 to 6 and get 1,208,925,819,614,629,174,706,176 hashes. This is without rolling the ntime at all. If that's not enough, rolling the ntime just once every second will give you 1,208,925,819,614,629,174,706,176 hashes per second.

That is one of the funniest posts I've read in a very long time 

cgminer times how long it takes for the gpu code to "return" after it's been given work. Unfortunately with windows, the timer resolution is so shithouse at 15ms that I have to sample many many iterations of the GPU code and then average them to see how long it took. This means that between giving the GPU code, there are short periods dependent on CPU code, and windows' scheduler does not seem to give this CPU code priority even though folding@home should be idle priority. So it ends up counting delays of the CPU scheduling as though the GPU had spent more time on its work. So it's a combination of the shit windows timer resolution and the shit windows scheduling that makes dynamic not work that well for your test case.
Thanks