Trend Micro does the same thing - just deletes the .exe. I switched to MSE and it wants to get rid of it, but I told it to ignore.

I received my two BFL singles so I'm trying out my self-compiled version of cgminer that disables opencl and enables bitforce.  These are the options I used when I compiled it (on windows):

CFLAGS="-O2 -msse2 --disable-opencl --disable-adl --enable-bitforce"

The two BFL singles are on COM8 and COM9, so I tried starting cgminer:

cgminer -o url:port -u user -p pass -S COM8 -S COM9

But I get an error:

-S: unrecognized option

Can you think of anything I'm missing?

That did it, thanks!

cgminer 2.4.1
Built with bitforce mining support.

It's mining now.

Why not just have a computer start mining at the appropriate time when it boots?
Thus when you have a power outage and it can't mine due to BFL's losing power ... the computer wont be doing anything either.
Then when power is restored and the computer boots up, it will then start mining again ...

Remove the battery

New version - 2.4.2, June 3rd 2012

Human readable changelog:
-Longpoll will now finally only connect to the main pool unless you switch pools, and then it will drop the longpoll on the next block if you are still on the new pool. This should complete the rework to make cgminer have the absolute optimum number of connections open at any one time - the minimum possible while having the best hashrate, and will likely decrease the lost work across block changes. No solution to multipool+LP here was going to be perfect but this seemed the best overall to miners and pools alike.
-The windows crash at 7 days which occurred thanks to the AMD driver fuckage should be fixed. Now it will behave the way it used to behave:you'll just lose your fan monitoring once the driver has fucked up.
-New Icarus code should scan more of each work item and has some hidden advanced timing options (see new readme file)
-Saved config file when there are no GPUs should no longer be corrupt.
-Separate READMEs for API and FPGA evolving.

Full changelog
- API.class compiled with Java SE 6.0_03 - works with Win7x64
- miner.php highlight devs too slow finding shares (possibly failing)
- API update version to V1.11 and document changes
- API save default config file if none specified
- api.c save success incorrectly returns error
- api.c replace BUFSIZ (linux/windows have different values)
- Move RPC API content out of README to API-README
- Open a longpoll connection if a pool is in the REJECTING state as it's the
only way to re-enable it automatically.
- Use only one longpoll as much as possible by using a pthread conditional
broadcast that each longpoll thread waits on and checks if it's the current pool
before
- If shares are known stale, don't use them to decide to disable a pool for
sequential rejects.
- Restarting cgminer from within after ADL has been corrupted only leads to a
crash. Display a warning only and disable fanspeed monitoring.
- Icarus: fix abort calculation/allow user specified abort
- Icarus: make --icarus-timing hidden and document it in FPGA-README
- Icarus: high accuracy timing and other bitstream speed support
- add-MIPSEB-to-icarus-for-BIG_ENDIAN
- work_decode only needs swab32 on midstate under BIG ENDIAN
- add compile command to api-example.c
- save config bugfix: writing an extra ',' when no gpus
- Add dpkg-source commits

Should I be running "--no-submit-stale " when I use BFL (FPGA)?

Probably not. "--no-submit-stale" is basically broken-by-design, but exists because it is technically required by the old longpoll specification. I say broken-by-design because it tries to guess which shares are stale based on insufficient information (this algorithm is also required by the old LP spec): whenever a longpoll is received, all shares found on old work is discarded. Many pools are using longpolls even when the old shares are still valid as a way to improve the Bitcoin network (by processing more transactions) - at least Eligius, EclipseMC, and TripleMining to my knowledge. p2pool also expects valid blocks to be found in stale shares, so you don't want to discard those either. Additionally, discarding stale shares makes all pools' website stats underreport your stale rate. So if you do use "--no-submit-stale", anything your pool tells you about your stales is wrong. On the other hand, submitting stales doesn't hurt unless your internet connection can't handle your mining rigs (in which case, your mining experience will suffer all the time there isn't a longpoll!).

Is there a known issue trying to run 5 or more BFL singles under windows in either 2.4.1 or 2.4.2?  2.3.6 seems to be able to handle 5 singles fine.  But every time I try to run all five under a single instance with 2.4.1 or 2.4.2, I get a crash in libpdcurses.dll.



Faulting application name: cgminer.exe, version: 0.0.0.0, time stamp: 0x4fcad128
Faulting module name: libpdcurses.dll, version: 0.0.0.0, time stamp: 0x4f460f95
Exception code: 0xc0000005
Fault offset: 0x000012fe
Faulting process id: 0xb24
Faulting application start time: 0x01cd419e02e067d8
Faulting application path: C:\Users\miner\Desktop\cgminer-2.4.2-win32\cgminer.exe
Faulting module path: C:\Users\miner\Desktop\cgminer-2.4.2-win32\libpdcurses.dll