title: What can cause VTable pointer to be 0xdddddddd in Win32 debug build?
body: <p>I am debugging a defect and have narrowed it down to the vtable pointer for an object being <code>0xdddddddd</code>.  <a href="https://stackoverflow.com/questions/370195/when-and-why-will-an-os-initialise-memory-to-0xcd-0xdd-etc-on-malloc-free-new/370362#370362">This answer</a> indicates that Win32 debug builds will generally set dead memory, or memory which has been deleted, to this special value.</p>
  
  <p>Note that the <strong>pointer</strong> itself looks valid, it's just the <strong>vtable pointer</strong> that is <code>0xdddddddd</code>.</p>
  
  <p>Here's a snippet of code:</p>
  
  <pre><code>std::list&lt;IMyObject*&gt;::const_iterator it;
  for (it = myObjects.begin(); it != myObjects.end(); ++it)
  {
      IMyObject* pMyObject = *it;
      if (pMyObject == 0)
          continue;
  
      pMyObject-&gt;someMethod(); // Access violation     
  }
  </code></pre>
  
  <p>If I break at the line of the access violation and watch <code>pMyObject</code>, I can see that <code>pMyObject</code> itself has a valid address (<code>0x08ede388</code>) but the <code>__vfptr</code> member is invalid (<code>0xdddddddd</code>).</p>
  
  <p>Some notes:</p>
  
  <ul>
  <li>It's a single-threaded application, so this is most likely not a race condition or mutex issue.</li>
  <li>There don't appear to be any obvious issues like deleting the object further up the call stack before accessing it.</li>
  <li>This issue seems to only be reproducible on Windows 2008 server, but not on Windows 7.</li>
  </ul>
  
  <p>Any suggestions about how to debug this further?</p>