Microsoft KB Archive/147256

{|
 * width="100%"|

HOWTO: How to Debug DirectDraw Applications

 * }

Q147256

-

The information in this article applies to:


 * Microsoft Windows Software Development Kit (SDK) 3.1

-

SUMMARY
There are two common needs when debugging DDraw applications:


 * Debugging a fullscreen application.
 * Debugging code between Lock and Unlock or GetDC and ReleaseDC calls.

MORE INFORMATION
The best way to debug fullscreen applications is to use remote debugging; that is, running the debugger on one computer and the application on another computer.

Whenever Lock or GetDC is called on a video memory surface, a Win16 Mutex (also called Win16Lock) is taken. Due to this, standard application debuggers such as Microsoft Visual C++ will not be able to debug the code that lies between Lock and Unlock or GetDC and ReleaseDC calls. A kernel debugger such as WDEB386 (provided with the Win32 SDK) or a third party debugger such as SoftIce for Windows 95 from NuMega Technologies must be used instead.

An alternative option for debugging a non-primary surface is to force an offscreen surface to use system memory. For example:

  #ifdef _DEBUG

ddsd.ddsCaps.dwCaps = DDSCAPS_SYSTEMMEMORY | DDSCAPS_OFFSCREENPLAIN;

#else

ddsd.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN;

#endif When a surface is explicitly requested to be allocated in system memory, Lock and GetDC do not take the Win16Mutex. If a surface is not specified to be placed in system memory but is allocated there anyway because there is not enough video memory available, the Win16Mutex will still be taken when the surface is locked.