The most common mistake made by developers using threadpool is to leave a worker thread in a dirty state after executing a callback function.

The application verifier helps detect these subtle errors, and helps in the development of a robust application.

The verifier hooks into all threadpool APIs that execute a callback (Work, Timer, Wait and I/O). It then substitutes its own contexts and parameter while encapsulating the users original data. The callback is then executed using the original context and parameters. The Verifier then compares the thread state before and after and generates warning and error messages if it differs.

The following state is checked for changes.

• Thread priority
  
  
• Thread affinity
  
  
• Orphaned critical sections
  
  
• Unclosed window resource
  
  
• Unprocessed messages in queue (window messages, etc)
  
  

The Application Verifier also checks for API misuse.

Following is a list of verifier stops that may occur when running the threadpool checks against a solution or project on different platforms:

Properties