Please visit the MSDN CHESS forum to ask questions about CHESS and get late-breaking news.  Also, see the CHESS documentation.

1. What programs can I run CHESS on? CHESS works on native (Win32) dlls and managed executables. Currently, we only support single-process binaries.
2. What tools are available in CHESS? There are several different ways to use CHESS. From the command line, you can either use wchess.exe to test unmanaged code or mchess.exe to test managed code. From Visual Studio Team System 2008, you can use annotate a unit test with HostType("Chess")to execute it under the control of CHESS.
3. How do I prepare my code to test it with CHESS?  For details on preparing your code for testing with CHESS, take a look at the CHESS documentation.
4. Can I run CHESS on my existing concurrency stress tests? Even though it is possible, we do not recommend you to run existing stress tests with CHESS. Stress tests attempt to indirectly increase thread-interleaving coverage by creating lots of threads. CHESS does not require this artificial bloat in your tests. Simplify your tests with the minimum number of threads required to expose your concurrency scenarios. Simply said, CHESS doesn't need hundreds of threads to find bugs in your code. In almost all cases, less than 10 threads should suffice.
5. Does CHESS work with multi-process, distributed and/or message-passing concurrent programs? No. Currently, CHESS can only analyze multithreaded single-process native or managed Windows programs.
6. What will happen if I run CHESS on a process that communicates with other processes? Bad things.  To enable deterministic testing for multithreaded programs, CHESS must take control of the scheduling of all asynchronous tasks in the program including the forked threads.  If an asynchronous task outside the control of CHESS, the external process for instance, introduces scheduling constraints, then CHESS can create an artificial deadlock in your process.  Similarly, if communication with the external process causes divergence in the control flow of your process, then testing with CHESS may not be deterministic any more.
7. Does CHESS scale to large programs? Yes & No. You can run CHESS on very large programs. In many cases, CHESS will find more bugs than stress testing. However, we do not recommend running CHESS on large programs. (Also see FAQ #4.) With CHESS, you have the ability to systematically explore the set of interleavings of your programs. You can maximize the benefit from this systematic exploration by providing lots of small tests, each exploring a different concurrency scenario. As the set of interleavings increases exponentially with the number of threads and the size of the program, the systematic exploration will not complete on large tests.
8. Why did CHESS not find the error I seeded in my program? By default, CHESS introduces preemptions only at accesses to synchronization operations.  If your program is data-race free, these preemptions are enough to find any possible bug in the program.  But if the program has a data-race, this strategy may miss errors.  For managed programs, CHESS provides an option (/volatile) to insert preemptions before every access to a volatile variable.  You can use this option to increase the number of interleavings generated by CHESS.
9. How does CHESS work? Take a look at our OSDI 2008 paper "Finding and reproducing Heisenbugs in concurrent programs" for an overview of the techniques used by CHESS.  The paper is available from the CHESS web site.
10. What is a preemption? A preemption is an unexpected interruption of the execution of a thread, usually to execute the code of some other thread. Preemptions arise from interrupts, the expiration of a thread's time slice, etc. In contrast, non-preemptive context switches take place because of the action of a thread, such as sleeping, yielding, or executing a blocking synchronization operation.
11. Where does CHESS schedule preemptions? By default, CHESS schedules preemptions at each synchronization operation, such as EnterCriticalSection, ReleaseCriticalSection, etc. Of course, a preemption may occur between any two instructions. However, even with this optimistic preemption scheme, CHESS is able to find many bugs. In fact, for a data-race free program, we can prove that CHESS' strategy of putting preemptions at every synchronization operation is guaranteed to not miss any errors. For managed code, accesses to volatile variables are racy by design. Therefore, CHESS provides an option (/volatile) to insert preemptions before every access to a volatile variable.
12. Can I add additional program points where CHESS inserts preemptions? Not yet. We will add this feature to CHESS very soon.
13. Why do I get the message "Detected nondeterminism outside the control of CHESS" when I run CHESS on my program? The goal of CHESS is to provide deterministic testing for multithreaded programs in which the only source of nondeterminism is thread scheduling.  CHESS runs your test function repeatedly, taking it through a different thread schedule each time.  CHESS reports this message when it detects any source of nondeterminism different from thread scheduling, such as the use of hardware counters or the time of day.  CHESS also reports this message if the test function does not bring the program state it was started in.  This commonly happens if global or static variables are initialized by the test function itself.  You should make sure that all initialization for the test occurs in the ChessTestStartup function; if necessary, execute ChessTestRun a few times in ChessTestStartup.