Once the problem has been documented and narrowed down to a specific event within a particular window, the developer must determine the Presentation Manager message that results from that event, or the first such message if multiple messages are generated.
A symbolic debugging tool is then applied to the application code, and a breakpoint is set at the commencement of processing for that message class. The program is then single-stepped to determine the operation or function call at which the error occurs.
Step #4: Single-step with a symbolic debugging tool to determine the code statement at which the error occurs.
It is important during this stage to note any WinPostMsg(), WinSendMsg() or WinBroadcastMsg() function calls performed by the program, which will generate additional Presentation Manager messages in the system. If the initial pass through the processing for the current message does not reveal the error, the same process must be performed for each of these messages and the window procedures that process them.
Note that this single-stepping process is most useful in situations where the error occurs every time a particular action is performed. In cases where the error only appears after a large number of repetitions, single-stepping will be time-consuming and unproductive. In such cases, the problem resolution process may be expedited by omitting the isolation phase and immediately checking the logic of the processing for the failing message, to ensure that all resources allocated during processing are subsequently released. See Repetitive Action Problems for more details.