This is painful since the mode of failure on windows is really a mystery. The best thing you can do for now is run in debug mode to give me even more indication of where the problem lies. Run it with "--verbose -D -T -P" and see what the last messages are before it crashes.

Even better would be a custom debug build running in gdb but I doubt any of you are up for that   I'm trying that on my laptop which is the only thing that has windows. Hopefully I don't fry it in the process, but at 10MH/s I also doubt it will recreate the problem.

Sigh. I wish it were only linux...

Sorry but a lot of miners mine without their mining rigs being connected to a bitcoind instance. Yes there may be one somewhere in their network, or possibly not at all and they only fire up their wallet when they want to on a separate network. What you think is ideal is asking people to do more than they currently do. They currently use pools and they trust them already. The community is very vigilant with respect to pools misbehaving. The importance of the miner doing it all themselves is grossly exaggerated by proponents of GBT. Pools will continue to do as much as they already do. It's unrealistic to expect otherwise.

Limited yes, useless no.

The miner can't hash anything without that merkle root though. I didn't see the merkle root being passed regularly to the miners in the sample on the wiki, just how to hash transactions as they come in and generate a merkle root. Did I miss where the merkle root is passed to the miner?

In which case, we're back to my original comment... the miners need all the transactions every so often or they're doing bitcoin a disservice.

I assume this is mining with stratum? Darn... the cause of this crash remains a mystery then. Perhaps someone with some windows debugging skills that can reproduce it (cause I can't reproduce it) can build a debug version and see.

As for XP mode helping? I doubt it, but it's worth a shot. Probably disabling stratum is the only way to guarantee it not crashing since it's a stratum error (give it regular server details and --fix-protocol)

So what are you anticipating the pools vs miners will be doing with transactions in pooled mining (ignoring p2pool)?

What a mess. With payloads increasing linearly with transaction count in GBT that makes each getwork equivalent much bigger than plain getwork already is the longer a block takes to solve. As bitcoin becomes more popular and transaction counts increase, gbt becomes less and less efficient. I'd hazard a guess that it may even be less efficient than plain getwork at some stage unless pools start ignoring transactions... there's a disincentive to include them.

Great thanks

I wouldn't worry about the Q value... hopefully the old getwork queue thing will be a thing of the past as pools move to better protocols like stratum.

Bug I guess. It's extraordinarily hard balancing things out when there are vastly different ways of getting the same amount of work and handing out depending on pool configuration.
If you strictly want a fixed proportion to each pool only the rotate strategy can guarantee that.

Yes you're not the only one to report this. Curious. I guess I can just ignore those defines on anything but linux.

I'm upgrading the status of cgminer 2.8.4 to stable status and removing 2.7.7 from the top directory. Even if some stratum bug does show up in the future, disabling stratum with --fix-protocol will still make it more stable than 2.7.7 is, and it's time to move on.

Don't take it to mean there's a bug. It's simply one less potential point of failure.

The main cgminer branch now includes this updated MMQ code thanks to Kano. Version 2.8.4 should work fine with MMQ on linux now.

Gimme a break 

Hopefully by now you should be able to cgminer directly to stratum pools more reliably than through the proxy.

2 minutes. It's there already.

EDIT: The problem is the proxy may have been lying and continuing to send what looked like fresh work to cgminer. It's time to stop  using the proxy

Very cool indeed 

Any chance you could document clearly somewhere what changes were needed to the code? It could be added to the main codebase.

New version - 2.8.4, 18th October 2012

Getting closer to something I can officially call a stable 2.8 release. Only testing will tell if windows+stratum is still crash prone.


Human readable changelog

Made the stratum code generally more reliable to indirectly address the unknown cause of win32 crashes with stratum.
Fixed stratum not declaring a pool alive again once it has reconnected to it.
Rewritten dynamic intensity code should fix remaining issues with it.
Fixes for building on windows.
Fixes for running on ARM architecture.
Padded hashrate display with zeroes when needed.
More information with high difficulty shares eg:
Pool difficulty will be rounded down in keeping with the share difficulty to avoid it appearing you are falsely getting accepted shares of lower difficulty than the pool is asking for.
Scrypt litecoin mining now shows the scrypt modified hex so it will start with lots of zeroes.
Share and pool difficulty is now shown with scrypt as well (but with an upper limit of 64k)
Scrypt will now not fail when setting high thread concurrency values that still return some ram even if opencl returns an error on that ram allocation.
Preliminary working version of MMQ code courtesy of kanoi works on linux (unknown on windows for now).
Updated opencl kernels which should allow ultra low memory speeds once again (idea courtesy of Vbs).


Full changelog

- Time for dynamic is in microseconds, not ms.
- x86_64 builds of mingw32 are not supported directly and should just configure
as generic mingw32 builds since they're NOT 64 bit.
- Cope with both ATI stream and AMD APP SDK roots being set when building.
- Use 3 significant digits when suffix string is used and values are >1000.
- MMQ new initialisation (that works) and clocking control
- Get rid of unused warning for !scrypt.
- Use select on stratum send to make sure the socket is writeable.
- Cope with dval being zero in suffix_string and display a single decimal place
when significant digits is not specified but the value is greater than 1000.
- Pad out the suffix string function with zeroes on the right.
- Failure to calloc in bin2hex is a fatal failure always so just check for that
failure within the function and abort, simplifying the rest of the code.
- Provide locking around the change of the stratum curl structures to avoid
possible races.
- Bump opencl kernel version numbers.
- Remove atomic ops from opencl kernels given rarity of more than once nonce on
the same wavefront and the potential increased ramspeed requirements to use the
atomics.
- Clear the pool idle flag in stratum when it comes back to life.
- Display correct share hash and share difficulty with scrypt mining.
- Use explicit host to BE functions in scrypt code instead of hard coding
byteswap everywhere.
- Show work target diff for scrypt mining.
- Ease the checking on allocation of padbuffer8 in the hope it works partially
anyway on an apparently failed call.
- Watch for buffer overflows on receiving data into the socket buffer.
- Round target difficulties down to be in keeping with the rounding of detected
share difficulties.
- Dramatically simplify the dynamic intensity calculation by oversampling many
runs through the opencl kernel till we're likely well within the timer
resolution on windows.
- String alignment to 4 byte boundaries and optimisations for bin<->hex
conversions.
- In opencl_free_work, make sure to still flush results in dynamic mode.
- Align static arrays to 4 byte boundaries to appease ARM builds for stratum.

No, a good hash function, and sha256 is that, will make the results have absolutely nothing in common even if only 1 bit is changed. This is called the avalanche effect and is a most desirable property.

http://en.wikipedia.org/wiki/Avalanche_effect