Windows has triggered a breakpoint in xxx.exe

The memory usage error can be inferred from this error, but this error is hidden. So it took me a whole day yesterday to find this error and finally found that a global variable Pointer Points to a member of a non-Global class instance. When the document is closed, this class is destroyed, but the global pointer is still present, and this becomes a wild pointer. The next time the document was opened, it was used again, so an exception occurred.

The pageheap.exe tool has helped a lot. After opening it, the error is basically located. Before using it, there is no doubt about the place where exceptions jump out every time. It may appear in various new places, which is extremely depressing. The following is a description of pageheap.exe.

 

PageHeap is recommended. exe and Gflags. the main reason is that when someone asks how to identify out-of-memory errors, foreign friends often recommend these two tools (highly recommend ). After I use it, I think it is good to use it sometimes.

PageHeap. Exe enables the Page Heap flag for a specified application to automatically monitor the memory allocation of all malloc, new, and heapAlloc and identify memory errors.

Download location of PageHeap. Exe:

Http://download.microsoft.com/download/vc60pro/utility/6.0/win98/en-us/pageheap1.exe

The following describes how to use PageHeap:

Step 1:

Run PageHeap. Exe in the command line. If you have previously set the enable Global Page Heap flag, you will see a list of all enabled applications with names, excluding paths.

As follows:

C: \> pageheap

Pgh.exe Enabled

Testsplit.exe Enabled

Step 2:

Compile a small program with the following code:

Void main ()
{
Int m_len = 5;
Char * m_p = (char *) heapalloc (getprocessheap (), heap_zero_memory, m_len );
M_p [m_len] = 0;
Heapfree (getprocessheap (), 0, m_p );
}

Build a debug version. You cannot see any reports of exceptions.

But in fact m_p [m_len] = 0 this sentence is written across the border, because only allocated to m_p [m_len-1]! This situation is called dynamic memory overrun. You can use boundschecker to check the vulnerability.

At this time, there was no problem on the surface, but a time bomb had already been buried.

Step 3:

Run PageHeap/enable YourApplicationName.exe 0x01 in the command line.

Run PageHeap without parameters again to check whether the preceding command takes effect. Your application should be in the enabled list.

Note: Do not add a path before YourApplication. Exe !!

The meaning of 0x01 is described later.

Step 4:

Run your program again.

You will notice a few more words before loading various DLL files in the Output window:

Loaded exports for 'C: \ WINNT \ System32 \ ntdll. dll'
Page heap: process 0x57C created heap @ 00130000 (00230000, flags 0x1)
Loaded 'C: \ WINNT \ system32 \ MFC42D. DLL ', no matching symbolic information found.
..
Loaded 'C: \ WINNT \ system32 \ MSVCP60D. DLL ', no matching symbolic information found.
Page heap: process 0x57C created heap @ 00470000 (00570000, flags 0x1)
Loaded exports for 'C: \ WINNT \ system32 \ imm32.dll'

This is the role of the Page Heap monitoring mechanism! He told you that your heap 00470000 was created.

After the program exits, the Output window has a few words indicating that there must be some errors:

Page heap: block @ 0015AFF8 is already upted (reason 10)
Page heap: reason: upted suffix pattern
Page heap: process 0x57C destroyed heap @ 00471000 (00570000)
The thread 0x8A8 has exited with code 0 (0x0 ).

This indicates the trouble encountered when destroying heap 00470000, that is, the data block 0015AFF8 was misused because of the misuse of the subscript syntax. Look, how clear it is! It also saves a lot of effort to check the code!

Note the following when using PageHeap:

1: Enabling PageHeap does not affect running applications. If you need to enable PageHeap for programs that are running and cannot be restarted, run PageHeap to enable it and restart the machine.

2: To view where PageHeap puts the information, open your registry and go to HKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Image File Execution Options.

You will see that your application is under this item. The GlobalFlag of your application is set to 0x02000000, and PageHeapFlags is set to 0x01.

3: the principle of pageheap is as follows: it puts several guard bytes behind the allocated memory, and then marks the memory page as page_noaccess. In this way, if the allocated memory is overwritten, the daemon byte will be changed. When the memory is released, pageheap will trigger an access violation (AV ). This is basically the case. So only when the problematic memory is finally released will the pageheap report be generated! This is the limitation of pageheap.

Description of parameter 0x01:

Flags HEX value (0x...) has the following structure:

B7-B0-bit flags 1-enable page heap

01-enable page heap. If zero normal heap is used. In 99% of the cases you will want this to be set.
02-collect stack traces (default on checked builds)
04-minimize memory impact
08-minimize randomly (1)/based on size range (0)
10-catch backward overruns

Have you seen it? You can also set the parameter to 0x10 to check the out-of-bounds write of memory!

Gflags. Exe is a tool in Microsoft's Debugging Tools. You can also find the Resource Kit in Windows 2000. We can also use it to complete the same tasks as PageHeap. Of course, Gflags. EXE can do many other things. We will not introduce it here. In short, it is worth the money.

The specific method is as follows:

1) Run Gflags. Exe;

2) you will see a dialog box. In the "Image File" edit box, write down the name of your application, such as YourApp. Exe. Do not specify the path!

3) Select the "Image File Options" radio button;

4) then, you will see a sudden change in the content of the dialog box. Select "Place heap"
The check box before allocations at ends of pages.

5) Click Apply.

In this way, the PageHeap effect is achieved. Now, run your program and overwrite your heap to generate an AV!

(Check Microsoft KB: SAMPLE: PageHeap1.exe Finds Heap upload uption and Memory Errors (q1_471 ))

 

Other people have encountered this problem and share some of them:

The process is like this. During the vc debug process, an assert window pops up:

Windows has triggered a breakpoint in cs.exe.

This may be due to a temporary uption of the heap, which indicates a bug in cs.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while cs.exe has focus.

View output:

Heap missing last entry in committed range near e6 ***** 630

Windows has triggered a breakpoint in cs.exe.

This may be due to a temporary uption of the heap, which indicates a bug in cs.exe or any of the DLLs it has loaded.

Check the memory directly:

0x0E6 **** 630 0e 00 0f 00 59 03 10 04 aa cd AB 00 10 72 85 38 00

I can't see anything. Go up and look at it again:

0 × 0E6 ***** 60C 07 e2 04 00 a8 01 66 0e 01 00 cd fd ....

It seems that this is the block heap memory. I can't see anything, so I decided to temporarily ignore it. After a few days, this error did not happen again.

But this error occurs one day before the test of the delivery program. It seems that a time bomb is buried in the program. It must be found out; otherwise, the consequences will be very serious.

The first thing we need to do is to reproduce this problem. If this problem happens every time, we can't help it. from the symptoms, it is a typical Heap upt. so use the tool pageheap to reproduce the heap damage.

The page heap tool is enabled in two ways: Full-page heap and Normal page heap.

The Normal page heap command is pageheap/enable xx.exe/normal.

Then set the symbol table via windbg: x: \ symbols_folder; srv * x: \ symbols_folder * http://msdl.microsoft.com/download/symbols

I started various debugging and almost used the commands in this book <> (the debugging process omitted 2000 words). When I almost collapsed, I suddenly saw such a passage in the book:

The normal page heap uses the fill mode to detect heap block corruption. You need to call the heap manager again after heap corruption occurs.

In addition to the specific fill mode, the full page heap also adds a protection page for each heap block. The protection page is a page of inaccessible memory, it is placed in the start position and end position of the heap block. prevents heap block overflow.

Directly set the full page heap mode by pageheap/enable xx.exe/full. re-run the program.

In an instant, the program collapsed. This is the first time I saw the program collapsed, so I was so excited. I checked the crashed code:

It turns out that a class pointer is strongly converted to a pointer of another subclass, and a function of the subclass is called, but this function does not exist. at the same time, a bool variable value is assigned to this subclass function, and the value is written to the heap address.

Summary

If you encounter similar problems in the future, directly enable pageheap full.