12th: puzzling NTDLL breakpoint

12th: puzzling NTDLL breakpoint

Handle unexpected user breakpoints in Ntdll

I haven't written anything for a long time. This time, I wrote a training ppt (VC usage and debugging skills) to help me remember to write something.
The following articles refer to http://www.debuginfo.com/tips/userbpntdll.html, but it is not a translation, and even English is too bad.

During program debugging, a dialog box is displayed suddenly, which displays the following information:
User breakpoint called from code at 0x77fa018c
Or
Unhandled exception at 0x77f767cd (NTDLL. dll) in myapp.exe: User breakpoint.
However, I have met the first message, but not the second one.

What's going on? We have not set a breakpoint! Why is there a user breakpoint?
In addition, this problem does not seem so serious. The program runs normally if it is not in the debugging status. Even if the dialog box is confirmed in the debugging status, continue F5, it seems that nothing has happened, and the program is still running normally!

Hidden Danger! Never ignore her! This information tells us that somewhere in the program has begun to collapse. If you frequently encounter this dialog box, it means that the collapse has expanded.

If you are careful enough, you will find that after you click the OK button in this dialog box, you will find an additional line of information in the output window:
Heapincludebuginfo2.exe]: heap block at 00030fd8 modified at 00031010 past requested size of 30

View the Stack window, which displays the following information:
Ntdll! 7c921230 ()
Ntdll! 7c97db9c ()
Ntdll! 7c98cd11 ()
Ntdll! 7c980af8 ()
Kernel32! 7c85e7af ()
_ Crtisvalidheappointer (const void * 0x00031000) line 1697
_ Free_dbg (void * 0x00031000, int 0x00000001) line 1044 + 9 bytes
Operator Delete (void * 0x00031000) line 49 + 16 bytes
Winmain (hinstance _ * 0x00400000, hinstance _ * 0x00000000, char * 0x00151f15, int 0x00000001) line 13 + 15 bytes
Winmaincrtstartup () line 198 + 54 bytes
Kernel32! 7c816d4f ()

It is easy to reproduce such a scene, with just a few lines of code.
Char * P = new char [4];
Lstrcpy (P, "this is a test ");
Delete P;

Why is there such an information message box? This is because in the debugging status, the operating system uses debugwin32heap to replace normal heap to allocate memory space. In any operation on the heap, the debug heap Manager checks the data integrity of the heap. If it finds an error, it reports a message.

So how can we know the cause of the error? If it is just similar to the Demo code above, you can discover and locate it without any skills. However, in most cases, the output window and callstack window do not allow us to precisely locate the information.

I can use boundschecker for runtime checks to find out the cause of this error. I personally think it is necessary to check the memory and resources before the program is released and run it completely under boundschecker. However, it is troublesome to use boundschecker every time.

There is another way to make this positioning more accurate.

That is, the pageheap mechanism provided after Windows 2000 sp2.

The text below is written by someone else. I copied it ,:)
When the pageheap mechanism of an application is activated, all heap allocations of the application are put into the memory, so that the heap boundary is ranked together with the virtual memory boundary. The Virtual Memory Page adjacent to the heap is set to no_access. Access to the space behind the heap in this application will immediately cause errors, which can be captured in a debugging tool. The process is similar when the heap is released. Pageheap modifies the virtual page of the released application to no_access. In this way, an access error occurs when the application attempts to read and write the internal storage. If you run the pageheap feature for an application, the application runs slowly and requires more virtual memory, because the allocation of each heap requires two complete virtual memory pages. As applications increase their usage of the heap, they may need to increase the virtual memory size of the system. Otherwise, an error message indicating insufficient virtual memory may occur. We recommend that you do not run more than two applications that activate the pageheap feature at the same time unless the system has a large virtual memory.

Let our program enable the full page heap mechanism, just in the Registry
Add the following settings under HKEY_LOCAL_MACHINE/software/Microsoft/Windows NT/CurrentVersion/Image File Execution options/yourappname.exe:
Globalflag, string type, value: x02200000
Pageheapflags, string type, value 0x3
Verifierflags, DWORD type, value: 00000001
Replace yourappname.exe with the name of your program. do not include a path.

If it is too troublesome, you can go to http://www.microsoft.com/whdc/devtools/debugging/installx86.mspxto download debugging tools for Windows. After installation, there is a gflags tool and use the following command:
Gflags-P/enable yourappname.exe/full
This tool helps you write the above registry project.
This tool is a GUI program. You can double-click it and set the relevant debugging portal.

If the full pageheap mode is set, an assertion dialog box appears before the confusing breakpoint dialog box is displayed during debugging and running. Haha, in this dialog box, there is a Retry button. Click it to enter the callstack. You can see what happened at this time.

If you write a DLL, you can also use this mechanism, but the value under the registry key must be set as follows:
Globalflag, string type, value: 0x02000000"
Pageheaptargetdlls, string type, value is the name of the debugged DLL, without path
Verifierflags, DWORD type, value: 00000001
Pageheapflags, string type, 0x403

Or use the command line
Gflags-P/enable yourappname.exe/full/DLLs yourdll. dll