warning C28616: Multithreaded AV condition

In a multithreaded environment, it is impossible to know when a thread is preempted, with the consequence that the apparent effect of reducing the reference count of an object is that it is deleted without further action on the part of the current thread. There should be no access to a reference-counted object after the reference count could potentially be at zero.


The following is an example of threading time sequence that could expose this problem:

A thread T1 executes lines 1, 2, and 3, decrements m_cRef to 1, and is preempted.

Another thread T2 executes lines 1, 2, and 3 decrements m_cRef to 0. Then it executes lines 4 and 5, where this is deleted, and finally executes line 6.

When T1 is rescheduled, it will reference m_cref on line 9. Thus it will access a member variable after the related this pointer has been deleted—and when the heap for the object is in an unknown state.

  1 ULONG CObject::Release()
  2 {
  3     if ( 0 == InterlockedDecrement(&m_cRef) )
  4     {
  5         delete this;
  6         return NULL;
  7     }
  8     /* this.m_cRef isn't thread safe */
  9     return m_cRef;
 10 }

The corrected example does not reference any heap memory after the object is deleted.

ULONG CObject::Release()
 ASSERT( 0 != m_cRef );
 ULONG cRef = InterlockedDecrement(&m_cRef);
 if ( 0 == cRef )
 delete this;
 return cRef;



Send comments about this topic to Microsoft

© 2014 Microsoft